Project

General

Profile

Actions

Bug #12502

closed

hammer host create using oVirt should use text IDs, not UUIDs

Added by Brad Buckingham over 8 years ago. Updated over 4 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Compute resources
Target version:
-
Difficulty:
Triaged:
No
Team Backlog:
Marek
Fixed in Releases:
Found in Releases:
In Kanboard:
yes

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1278534
Description of problem:

Using RHEV as a a compute resource and following the documentation (https://gist.github.com/tstrachota/f7858388976f19317b73) for RHEV (oVirt) related options I can not create a host using hammer CLI. Using UI works fine.

Sample command:

hammer -d host create --name dhtesthost4 --organization ACME --location 'munich' --hostgroup-id 33 --compute-resource acme-rhev-munich --compute-attributes 'memory=2147483648,cores=2,start=true,cluster=COE_RHS' --root-password 'redhat2015' --volume="size_gb=25,storage_domain=EQL_RHEV34,bootable=true" --partition-table 'ptable-acme-os-rhel-server' --interface 'name=eth0,network=v96'

Tried with many combinations of parameters, with and without compute profiles. Error message does not explain why it fails (422 Unprocessable Entity).

While debugging it with the help of Og we've figured out that the command used while creating a host using the WebUI converts the RHEV specific attributes into UUIDs.

Using the UUIDs for network and storage the hammer command successfully creates a host:

hammer -u admin -p redhat host create --name='rhel-7-server-omaciel-02' --root-pass='abracadabra' --organization='ACME' --location=munich --hostgroup="omaciel" --compute-resource-id=1 --compute-attributes="cluster='6a9a01e7-ee59-4fe3-817a-54d85612c124', cpus=2, memory=2147483648, start=1" --interface="name=eth0, network='6337e786-f7ab-4d3b-901d-09346baf8278'" --volume="size_gb=25, storage_domain='cde2d7fb-9673-4361-845a-009c4e203d30', bootable=true"

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a host using hammer with the first command mentioned above.
2. Check if the host has been created.
3. Try the second command (requires to adapt UUIDs)

Actual results:

Host is only created using the UUIDs

Expected results:

Host is created using the human readable parameter as used in the WebUI.

Additional info:


Related issues 3 (0 open3 closed)

Related to Hammer CLI - Tracker #16829: Tracker for compute resource related issuesClosed

Actions
Related to Hammer CLI - Tracker #18935: Tracker for issues related to processing of nested options in host createClosed

Actions
Related to Hammer CLI - Tracker #26990: Tracker for VMware issuesClosedOleh Fedorenko

Actions
Actions #1

Updated by Dominic Cleal over 8 years ago

  • Project changed from Foreman to Hammer CLI
  • Subject changed from hammer host create using RHEV does not work to hammer host create using oVirt should use text IDs, not UUIDs
  • Category set to Foreman commands (obsolete)
  • Assignee deleted (Ohad Levy)

There are APIs for looking this up, it can be done on the client side.

Actions #2

Updated by Tomáš Strachota over 7 years ago

  • Target version set to 115

We actually use IDs/UUIDs instead of names for all compute resources. Ideally the patch should fix it for all of them.

Actions #3

Updated by Tomáš Strachota over 7 years ago

  • Category changed from Foreman commands (obsolete) to Compute resources
Actions #4

Updated by Marek Hulán over 7 years ago

  • Assignee set to Tomáš Strachota
  • Target version changed from 115 to 1.5.0

as agreed yesterday, we can start with the concept and implementation for vmware CR and split other CRs into separate issues since it would be too big patch

Actions #5

Updated by Tomáš Strachota over 7 years ago

  • Related to Tracker #16829: Tracker for compute resource related issues added
Actions #6

Updated by Marek Hulán over 7 years ago

  • Target version changed from 1.5.0 to 1.4.2
Actions #7

Updated by Marek Hulán over 7 years ago

  • Target version changed from 1.4.2 to 1.4.4
Actions #8

Updated by Marek Hulán over 7 years ago

  • Target version changed from 1.4.4 to 115
Actions #9

Updated by Tomáš Strachota about 7 years ago

  • Related to Tracker #18935: Tracker for issues related to processing of nested options in host create added
Actions #10

Updated by Davide Ferrari almost 7 years ago

What's the schedule for this fix?
In the meanwhile, is there a programmatic way to get those cluster's UUIDs using hammer or, as a second option, using the Foreman API?

Actions #11

Updated by Tomáš Strachota almost 7 years ago

Unfortunately there's no planned schedule for fixing this issue. In the meantime you can use API endpoints for fetching cluster's UUIDs.

See the api doc:
https://theforeman.org/api/1.15/apidoc/v2/compute_resources.html
Namely the endpoint for listing clusters:
https://theforeman.org/api/1.15/apidoc/v2/compute_resources/available_clusters.html

Actions #12

Updated by Oleh Fedorenko almost 5 years ago

Actions #13

Updated by Shira Maximov over 4 years ago

  • Assignee deleted (Tomáš Strachota)
  • Triaged set to No
Actions #14

Updated by Shira Maximov over 4 years ago

  • In Kanboard set to yes

Changing the

Actions #15

Updated by yifat makias over 4 years ago

  • Status changed from New to Duplicate

This is a duplication of a bug that has already been fixed:
https://projects.theforeman.org/issues/25281
https://projects.theforeman.org/issues/28464

Actions

Also available in: Atom PDF