Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2097271

Summary: Set tripleo cloud init timeout through templates
Product: Red Hat OpenStack Reporter: Miguel Angel Nieto <mnietoji>
Component: openstack-tripleo-heat-templatesAssignee: OSP Team <rhos-maint>
Status: CLOSED WONTFIX QA Contact: Joe H. Rahme <jhakimra>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.2 (Train)CC: bshephar, hakhande, jkreger, mburns, sbaker
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-04 20:04:54 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 Miguel Angel Nieto 2022-06-15 10:23:40 UTC
Description of problem:
Sometimes operator will need to configure cloud-init timeout during deployment, it would be  usefull if it would be possible to configure it through templates as an optional value. 

For example, in this case [1] where there is a firmware update of a nic, it is taking longer than the default value and deployment is failing

Currently it is configured to 50 retries each 5 seconds (around 250 seconds)

/usr/share/openstack-tripleo-heat-templates/common/deploy-steps-tasks-step-0.j2.yaml
- name: Wait for cloud-init to finish, if enabled
  cloud_init_data_facts:
    filter: status
  register: res
  until: >
    res.cloud_init_data_facts.status.v1.stage is defined and
    not res.cloud_init_data_facts.status.v1.stage
  retries: 50
  delay: 5
  when:
    - cloud_init_enabled.rc is defined
    - cloud_init_enabled.rc == 0
    - cloud_init_vendor_disabled.rc is not defined or cloud_init_vendor_disabled.rc != 0

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2042143#c28


Version-Release number of selected component (if applicable):
RHOS-16.2-RHEL-8-20220603.n.1


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Steve Baker 2022-10-04 20:04:54 UTC
Rather than using cloud-init for early provision firmware upgrade, we would suggest using the ansible_playbooks directive[1] in the provision yaml. This is the mechanism we support for this sort of task, and there are already established patterns for tasks triggering a reboot and waiting for the node to be available again (for example, cli-overcloud-node-kernelargs.yaml).

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/17.0/html/director_installation_and_usage/assembly_provisioning-and-deploying-your-overcloud#ansible-playbooks-properties