Hello there, There has been multiple issues with module stream activation within OSP deploy, especially for the container-tools one. If an operator overlooks the stream activation, they will end with the wrong tooling version (in container-tools case, wrong podman), and it will lead to tons of useless support tickets, failures and other bad things. Some attempts were made, among them a hard pinning of the podman version, or even some hack in RPM spec file such as https://review.rdoproject.org/r/#/c/31411/ But none of those solutions are actually usable nor providing a good user experience. Therefore, we can learn from multiple places: - upstream and its "tripleo-repos", specifically this patch: https://review.opendev.org/c/openstack/tripleo-repos/+/767214 - downstream and the rhosp-release, used for developers only at this time. The idea here is to make things easier, automated, and cleaner for everyone: - activate the proper subscription - install one package, let's call it "osp-release" - run "osp-release 17.0" The command will then: - ensure proper subscriptions are present and active - switch the modules to the correct streams - [optional] run some validations[1] in the process Once the command is successful (and validations are green), the operator will be able to deploy the Director node, and then proceed to the Overcloud deploy. A nice addition would be to support an upgrade, for instance by issuing "osp-release --upgrade 17.1" or something like that - some more checks can be done, such as ensuring older repositories aren't enabled anymore (and, here again, some more validations as pre-upgrade). Such a tool will really improve the overall UX regarding the deploy and, if the "nice addition" is also implemented, pre-upgrade tasks. This tool might be a subpackage of the rhosp-release, or a brand new repository (though there will be code duplication, and this is bad ;)). Thank you for your consideration! Cheers, C. [1] Using the Validation Framework, we can leverage quick validations. In order to do so, the package will have to depends on "validations-common" and, to some extend, "python3-validations-libs" (validations-common already depends on python3-validations-libs anyway). It provides python libraries allowing to run a subset of validations on the host, and present the result in a convenient way.
So, after more discussion, the initial goal is to add a yaml file to rhosp-release in a well-known location that can be called from openstack-tripleo-validations, which specifies: - RHEL version - Module names and streams, if they are not the default provided This could then be validated by openstack-tripleo-validations.
Note that tripleo-repos apparently ships such a thing already: https://review.opendev.org/c/openstack/tripleo-repos/+/767214 Might be good ensuring we follow the same format and location, that would make the whole validation work far easier :).
It sounds like other solutions are in progress, but I've created a yaml based on Alex's work that is ... quasi-similar.
Created attachment 1754854 [details] Naïve clip/update
Link to the documented repositories: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/director_installation_and_usage/planning-your-undercloud#undercloud-repositories
Per a conversation this morning, the use case for this tool would be: As a user I would like to be able to install a single tool that can the following given a specific OpenStack version: 1) (Optionally) Configure required Operating System, OpenStack, and Extra RPM (ceph, ansible, HA, fast data path, etc) repositories on the local system 2) (Optionally) Configure dnf modules required for specific dependencies (e.g. container-tools, advanced-virt, etc) 3) (Optionally) Install tripleoclient 4) (Optionally) Validate configured repos & modules match expected versions Each one of these features should be optional with a default of being enabled. This would allow a customer to install a single tool that should take care of the complexities of the initial setup while allowing for manual intervention of specific actions. Additionally this can be used to ensure proper initial setup as part of upgrades and FFU related actions. Example invocations: $ sudo openstack-version-setup 16.1 $ sudo openstack-version-setup --skip-repos --skip-client-install --skip-validation 16.1 The tool is only targeted for the end user and not CI, Development, or QE. The tool can be leveraged by existing tools that are used upstream & downstream to handle the CI, Developer, and QE workflows. A data file will need to be shipped that contains the required metadata to express the repository and module dependency information in addition to the tool itself.
This basically should handle items 3.2 -> 3.4 (and maybe 3.5) of https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/director_installation_and_usage/preparing-for-director-installation#registering-the-undercloud-and-attaching-subscriptions
Since we expect a user to update & reboot, we may wish to allow for the tool to optionally handle that as well (default off) as well as a flag for installing ceph-ansible