Bug 1332117

Summary: hammer host create ignores compute attributes for NICs when --compute-resource param is used
Product: Red Hat Satellite Reporter: Tomas Strachota <tstrachota>
Component: HammerAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: Sachin Ghai <sghai>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1.8CC: bbuckingham, bkearney, chrobert, cwelton, inecas, mhulan, pmoravec, sghai, tstrachota
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-27 11:02:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Tomas Strachota 2016-05-02 09:20:16 UTC
Description of problem:

hammer host create sends compute attributes for network interfaces in a wrong field when parameter --compute-resource is used. This causes NICs not being created on the compute host. Everything works fine with --compute-resource-id.

hammer -d host create --name rhel7 --compute-resource "RHEV-M" --interface="name=ens192,network=rhevm" ...

Results in POST to /api/hosts with:
"host" => {
  "interfaces_attributes" => {
    "0" => {
      "name" => "ens192",
      "network" => "rhevm"
    }
  }
  # ...
}

while the same command with --compute-resource-id sends:
"host" => {
  "compute_attributes" => {
    "interfaces_attributes" => {
      "0" => {
        "name" => "ens192",
        "network" => "rhevm"
      }
    }
  }
  # ...
}

Only the latter is correct.


Steps to Reproduce:
1. Create a host on a compute resource of your choice via hammer with -d. Use --interface to set some of the compute attributes.
2. See output logs of the command and check the attributes sent to POST /api/hosts .
3. Depending on compute resource type the process will either end up with an exception because of missing data for NICs or the host will be created with default NIC (completely ignoring params from --interface)

Comment 7 Sachin Ghai 2016-05-18 09:38:33 UTC
Verified with sat6.2 GA snap11.0

I think this issue is reproducible with snap11.0

I created a host with following hammer cmd on libvirt.

hammer -u admin -p changeme host create --name="test-host6" --environment-id="1" --domain-id="1" --puppet-proxy-id="1" --hostgroup-id 2 --compute-attributes="cpus=1, memory=2147483648," --volume="capacity=10G,format_type=qcow" --compute-resource-id=1 --interface="network-type='Virtual (NAT)', network=foreman"  --location-id=2 --organization-id=1 --root-password dog8code
Host created


From debug logs, api is passing network-type as below and when I checked webUI, UI shows "network-type -> Physical (Bridge)"


  "host_parameters_attributes" => {},
             "interfaces_attributes" => [
            [0] {
                "network-type" => "Virtual (NAT)",
                     "network" => "foreman"
  
Please note I'm passing --compute-resource-id=1


@tstrachota: Please correct, If I'm missing anything ?

Comment 8 Tomas Strachota 2016-05-19 12:00:12 UTC
Hi Sachin,
This is a bit different issue. Format of the interface options has slightly changed since 6.1. Please see https://github.com/theforeman/hammer-cli-foreman/blob/master/doc/host_create.md for details. You're passing wrong options and therefore the default's get applied.

So the issue you're facing is rather "Missing validation for interface compute attributes" while this bug's problem is "Even if I send correct attributes, they are ignored when compute resource is specified by name". I'd handle it in a separate BZ.

Comment 10 Bryan Kearney 2016-07-27 11:02:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1501