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:
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
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
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
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