Bug 1916329

Summary: [RFE] Provide an equivalent of rhos-release to the Customers with some additional features
Product: Red Hat OpenStack Reporter: Cédric Jeanneret <cjeanner>
Component: rhosp-releaseAssignee: Jason Joyce <jjoyce>
Status: CLOSED WONTFIX QA Contact: Arik Chernetsky <achernet>
Severity: high Docs Contact:
Priority: high    
Version: 17.0 (Wallaby)CC: apevec, bdobreli, gchamoul, jjoyce, jpichon, lhh, pweeks, whayutin
Target Milestone: AlphaKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-10 19:23:15 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:
Bug Depends On:    
Bug Blocks: 1918819    
Attachments:
Description Flags
Naïve clip/update none

Description Cédric Jeanneret 2021-01-14 14:41:37 UTC 
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.
Comment 1 Lon Hohberger 2021-01-21 15:28:26 UTC 
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.
Comment 3 Cédric Jeanneret 2021-01-22 07:52:10 UTC 
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 :).
Comment 4 Lon Hohberger 2021-02-03 19:04:20 UTC 
It sounds like other solutions are in progress, but I've created a yaml based on Alex's work that is ... quasi-similar.
Comment 5 Lon Hohberger 2021-02-03 19:09:32 UTC 
Created attachment 1754854 [details]
Naïve clip/update
Comment 6 Cédric Jeanneret 2021-02-08 15:47:26 UTC 
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
Comment 7 Alex Schultz 2021-02-08 22:15:09 UTC 
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.
Comment 8 Alex Schultz 2021-02-08 22:27:58 UTC 
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
Comment 9 Alex Schultz 2021-02-08 22:29:04 UTC 
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