Add the hypervisors to the inventory

[pablintino]

For use cases like ShiftOnStack the deployment may need to tweak the hypervisor.
We did not have a way to tell the deployment how to reach the hypervisor so this commit exposes the hypervisor Ansible instance to each host and creates a hypervisors group in the generated inventory.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from pablintino. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

Thanks for the PR! ❤️
I'm marking it as a draft, once your happy with it merging and the PR is passing CI, click the "Ready for review" button below.

[hjensas]

So shift-stack needs to re-wire the datacenter networking, add install more RAM servers and/or modify the routers or the DNS configuration? This seems like a problem with separation of concerns? My worry here is that we it will be harder to move this automation to a different platform (cloud or hardware) in the future.

Would it not be possible to pre-seed whatever is required in the hypervisor with the "module" that creates the infrastructure? (libvirt-manager)

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/1e87b2c68bc74710b55c0fdd58fe8ed2

✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 29m 21s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 17m 11s
❌ cifmw-crc-podified-edpm-baremetal FAILURE in 40m 23s
✔️ noop SUCCESS in 0s
✔️ cifmw-pod-ansible-test SUCCESS in 7m 39s
✔️ cifmw-pod-pre-commit SUCCESS in 7m 57s
✔️ build-push-container-cifmw-client SUCCESS in 36m 06s
❌ cifmw-molecule-libvirt_manager FAILURE in 11m 33s
❌ cifmw-molecule-reproducer FAILURE in 8m 34s

[pablintino]

So shift-stack needs to re-wire the datacenter networking, add install more RAM servers and/or modify the routers or the DNS configuration? This seems like a problem with separation of concerns? My worry here is that we it will be harder to move this automation to a different platform (cloud or hardware) in the future.

Would it not be possible to pre-seed whatever is required in the hypervisor with the "module" that creates the infrastructure? (libvirt-manager)

@hjensas no, shift-stack needs to add a DNS entry in the hypervisor that can only be added after the payload OCP cluster is deployed, that's is, after they deploy OpenShift on top of RHOSO.
May it imply a separation of concerns problem? Sure, but I don't think there's a quick way to accomplish this in the framework that is not this one.

[github-actions]

Thanks for the PR! ❤️
I'm marking it as a draft, once your happy with it merging and the PR is passing CI, click the "Ready for review" button below.

[hjensas]

So shift-stack needs to re-wire the datacenter networking, add install more RAM servers and/or modify the routers or the DNS configuration? This seems like a problem with separation of concerns? My worry here is that we it will be harder to move this automation to a different platform (cloud or hardware) in the future.
Would it not be possible to pre-seed whatever is required in the hypervisor with the "module" that creates the infrastructure? (libvirt-manager)

@hjensas no, shift-stack needs to add a DNS entry in the hypervisor that can only be added after the payload OCP cluster is deployed, that's is, after they deploy OpenShift on top of RHOSO. May it imply a separation of concerns problem? Sure, but I don't think there's a quick way to accomplish this in the framework that is not this one.

ack, I am guessing but this must be for the API and Ingress addresses on a provider network. It would be possible to provide the addresses in install-config - but they may have a valid reason to explicitly test without setting them statically.

/lgtm

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/02acabc3ab3741b6bdc3c938a1612ebe

✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 32m 48s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 19m 02s
❌ cifmw-crc-podified-edpm-baremetal RETRY_LIMIT in 21m 05s
✔️ noop SUCCESS in 0s
✔️ cifmw-pod-ansible-test SUCCESS in 7m 43s
✔️ cifmw-pod-pre-commit SUCCESS in 7m 19s
✔️ build-push-container-cifmw-client SUCCESS in 38m 16s
❌ cifmw-molecule-libvirt_manager FAILURE in 12m 01s
❌ cifmw-molecule-reproducer FAILURE in 8m 33s

[eurijon]

It's been tested from #2596 and the hostname is correctly retrieved:

2024-12-24 05:31:23,460 p=25595 u=zuul n=ansible | TASK [shiftstack : Debug hypervisor ansible_host msg=hypervisor ansible_host: {{ hostvars[hostvars['controller-0']['cifmw_hypervisor_host']]['ansible_host'] }} ] ***
2024-12-24 05:31:23,460 p=25595 u=zuul n=ansible | Tuesday 24 December 2024  05:31:23 -0500 (0:00:00.376)       1:04:03.311 ****** 
2024-12-24 05:31:23,527 p=25595 u=zuul n=ansible | ok: [localhost] => 
  msg: 'hypervisor ansible_host: titan19.lab.eng.tlv2.redhat.com '

For context, we set the API and Ingress FIPs in the install-config.yaml but those FIPs are created before cluster provisioning (outside ci-framework). The FIPs could be reserved, but that requires additional logic in ci-framework for FIP management, and significant changes in the shift-on-stack automation too. On the other hand, the Ingress hostnames depend on the cluster name, which can be different for each cluster. That's why adding the DNS entry in the hypervisor after shift-on-stack cluster deployment seems the most reasonable way.