Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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