Bug 1871815

Summary: Satellite Ansible Collection - Provisioning a host fails with timeout
Product: Red Hat Satellite Reporter: Luka Bac <lbac>
Component: Ansible CollectionAssignee: Evgeni Golov <egolov>
Status: CLOSED ERRATA QA Contact: Peter Ondrejka <pondrejk>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.7.0CC: egolov, robin.jonsson7
Target Milestone: 6.8.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ansible-collection-redhat-satellite-1.2.0 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-27 13:05:30 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:
Embargoed:

Description Luka Bac 2020-08-24 11:07:49 UTC
Description of problem:
Attempting to use the redhat.satellite collection to provision a machine via the host module with a compute_resource from VMWare and a provision_method of image.

This works, insofar as the host gets created in Satellite, and the VM gets provisioned in VMWare,... however - the VM does not get started in VMWare, so the Ansible task fails after a timeout with the following error:

                "Failed to login via SSH to <HOSTNAME>: execution expired"

If the VM is started manually from VMWare/Satellite before the task times out, then the task proceeds and finishes successfully.

Version-Release number of selected component (if applicable):
Red Hat Satellite Ansible Collection v1.0.1

How reproducible:
Always

Steps to Reproduce:
1. Have a VMWare compute_resource
2. Run the ansible task to provision a new host with the resource and image
3. Fail

Actual results:
Host provisioned in Satellite and VMWare, but not started.
Task fails with "Failed to login via SSH to <HOSTNAME>: execution expired"

Expected results:
Host provisioned in Satellite and VMWare, Satellite finishes the provisioning.
Task succeeds.

Additional info:

Comment 1 Evgeni Golov 2020-08-24 13:58:31 UTC
So if I'm not mistaken from reading the API docs, we'd need to pass "{compute_attributes: {start: true}}" to the API, but we currently can't: https://github.com/theforeman/foreman-ansible-modules/issues/788

Comment 2 Luka Bac 2020-08-24 16:49:02 UTC
I do think this is the correct way around to fix this, but on the other hand, it would be more user friendly if the module had a way of passing this as well.

Moreover, since there is no way to set this in the UI, we had to do it with the compute_attribute module, which,... has no easy way of appending to the vm_attrs dictionary - ie, we need to specify the whole thing, else we override everything.






We did manage to workaround the issue for now, by using the 'compute_attribute' module to add 'start: 1' to the compute_attribute associated with the compute_resource/compute_profile combination.

Notably, we also tried with 'start: true', and that did not work, presumably because of boolean/string semantics. (perhaps 'start: True' would have worked)

This is a suboptimal solution, however, since:
A) The compute_attribute module replaces the whole vm_attrs dictionary with its parameters and there is no easy way of simply appending a value to it.
B) If anyone changes the compute_profile in the UI, the compute_attributes are overwritten and the 'start: 1' value is gone.

The invocation of the compute_attribute module that worked:

- name: "Update compute attribute"
  redhat.satellite.compute_attribute:
    username: "{{ username }}"
    password: "{{ password }}"
    server_url: "{{ server_url }}"
    compute_profile: "{{ compute_profile }}"
    compute_resource: "{{ compute_resource }}"
    vm_attrs:
      [...]
      start: "1"
      [...]
    state: present

Comment 4 Peter Ondrejka 2020-09-30 12:55:43 UTC
Verified on Sat 6.8 snap 17 using Libvirt CR, compute attributes can be passed to the host module and are correctly applied in provisioning

Comment 7 errata-xmlrpc 2020-10-27 13:05:30 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 (Important: Satellite 6.8 release), 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/RHSA-2020:4366

Comment 8 errata-xmlrpc 2020-10-27 13:08:49 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 (Important: Satellite 6.8 release), 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/RHSA-2020:4366