This Epic captures all the work needed to bump OCP to 4.18 in both deploy strategies the framework supports now: crc and dev-scripts.

 RHOSO 18.0 should support both OCP 4.16 and 4.18 for FR2.

The outcome of this Epic will be:

• CIFMW support the ability of zuul nodesets for crc based deployments to be updated to a 4.18 label
• CIFMW support the ability for devscripts OCP version value to be bumped to 4.18.0

To minimize the impact of depending too much on the release of official builds of OCP and crc (that usually releases ~7/15 days later) this Epic will cover work to improve the way we consume crc by using crc-cloud. With that in place we will be able to early consume RC builds that will give us a bit more of margin fixing breaking changes.

Priority by order:

Downstream:

1. Integration jobs - Devscripts basesd deployment, some medium work may be needed to add support for deploying pre-release OC
2. Component jobs - Adoption, extracted and nested CRC jobs.

Upstream:

      3. Github check - Adoption, extracted and nested CRC jobs.
      4. Prow Jobs - Hive cluster pools and Prow jobs need to be slowly migrated to from 4.16 to 4.18

The execution plan in order:

1. Complete the spikes to ensure we have the complete scope of the work.
2. Add CI-Framework testing for 4.18 devscripts deployments
3. Signal devops can test and bump integration jobs
4. Complete tasks identified by https://issues.redhat.com/browse/OSPRH-11619
5. Add new CRC 4.18 nodesets downstream
6. Add CI-Framework testing for 4.18 CRC cloud deployments downstream
7. Signal devops can test and bump component jobs
8. Add new CRC cloud 4.18 nodesets upstream
9. Add CI-Framework testing for 4.18 CRC cloud deployments upstream
10. Test and bump github-check jobs
11. Create 4.18 Hive Cluster Pool with 3 nodes
12. Test some Hive dependent jobs on the new Cluster Pool
13. Move all Prow jobs to 4.18 - To be confirmed

Current Status:

The issue is 4.18 deploys fine but RHOSO depends on some external operators like nmstate and metellb, we don't currently have support for deploying pre-release versions of those operators and it may not be worth the investment. I have asked the DFGs to see if anyone is interested or has a solution already.

For now, this card is on hold until GA