Enable continous relase (CR) repo Design

tags: Design

What is CR repos?

The continuous release (CR) repository makes generally available packages that will appear in
the next point release of CentOS, on a testing and hotfix basis until formally released.

Where it is enabled previously?

In Fs021, https://opendev.org/openstack/tripleo-quickstart/src/branch/master/config/general_config/featureset021.yml#L246
It was enabled earlier. From master release, this job no longer exists due to existance of multiple standalone scenarios.

Why we used it in our CI in one job?

To find issues and breakages early from the early released contents of the upcoming new CentOS 8.x and 7.x versions without disturbing
the existing pipeline

Where we find issues early in promotion pipelines?

Now a days component pipeline is the first line of defence and integration pipeline is the second line of defence. So finding issues early using
component pipeline is the goal.

What is the problem with the previous fs021 job?

As fs021 job was always failing, we had given less attension to this job and also leading to wasting resources.

Things to keep in consideration for new design

• Donot waste resources
• Make sure failure gets tracked and monitored regularly
• We are finding issues in first line defence.

Current proposed design and problems with that?

Enabling cr repos in duplicated version of fs02 jobs using featureset override

• [TQ] Add enable_centos_cr_repo var in release file - https://review.opendev.org/#/c/737015/
• [TOCI] Add enable_centos_cr_repo to fs override - https://review.opendev.org/736999
• [rdo-jobs] Added fs02 cr repo based jobs - https://review.rdoproject.org/r/#/c/28168/

Remarks

​​​​* It does not take the above consideration, so it is not valid.

Adding a seperate component pipeline where cr repos will be enabled

• [rdo-jobs] WIP: Add component job for centos-8 CR repo - https://review.rdoproject.org/r/#/c/28489/

Remarks

​​​​* It will provide value in component pipeline.
​​​​* things that needs to improved:
​​​​    * Make sure the all the jobs passes
​​​​    * Repo needs to be enabled only when contents are available there
​​​​* If it fails, it should block the promotion
​​​​* Naming is hard, we can think about that (are we talking one component line per repo or an 'external components line to keep all the tests?')
​​​​* If we consider CR a component, we will have to make some changes to get_hash to support that
​​​​* Speaking of get_hash ... it would be good to have a way to identify the repo we tested. Like the md5 hash we have so we have some tracking/reporting
​​​​* Do we care about reporting to dlrn? If not, we may be able to by pass some changes.

Further extensions

Right now we have third party jobs exists like podman and ceph-ansible, May we we can add build the rpms of podman and ceph-ansible and create a third party repo with cr repos and add the same in this new component pipeline and monitor that.