branching strategy for COSA for Openshift

[dustymabe]

Typically we have branched COSA everytime we branch for a new OCP release. i.e. the rhcos-4.18 branch is for OCP 4.18 builds.

This has served us well, but we are moving in OpenShift to a model where we do a base image build that is purely RHEL content and no OCP content and using that rhel content stream (i.e. rhel-9.6) as the input to a layered container build that adds the OCP content.

This means we'll use a base RHEL stream (like rhel-9.6) for multiple versions of Openshift at the same time. Ultimately the branching of COSA might not make sense anymore since there is no 1:1 relationship between RHCOS stream to Openshift release.

We could either:

1. Stop branching at all and just use latest
2. Maybe branch differently where we branch for the rhel stream verses an openshift release

With the first option we'd have to be more careful about large changes (like big new features) and with the second option we'd probably need to "backport" a lot of changes from one branch to another as we'd have multiple branches that are essentially latest development streams.

WDYT?

[travier]

I'm for the second approach. We don't have a way right now to test older openshift branches on COSA changes so using latest would be a significant risk for stable releases.

We should start creating RHEL EUS branches for COSA. Ideally in the future the role of COSA should shrink for building the OS (as we move to a container build) and disk images (as we converge on a disk image building tool), so maybe once we get there, we can start using latest again as it would be mainly used for testing using kola.

[jlebon]

First, it's worth noting that we'll be building RHEL 9.6 and 10.1 for quite a while (until we prepare for 4.22). So by the time, we would branch, we should already be in a position where cosa matters a lot less.

Second, given that we'll be building RHEL 9.6/10.1 for a while across multiple OCP versions, we're already in a position where we have to be careful about the changes we make because they will affect multiple OCP versions.

So overall, I'm for not branching but we can defer this anyway until 4.22 where we have more information and experience to inform our decision.

[dustymabe]

re: waiting and making the decision later

I think if we choose 2. we'd need to branch now i.e. we'd create a rhel-X.X branch at the same time the first release of OpenShift that branched using that release did and hypothetically we'd only backport things we needed to that branch.

I'm not advocating for doing that. I'm just stating that I don't think it makes sense to wait.

Not branching now would be choosing 1. Of course we can change strategy later if we want.

[jbtrystram]

I think if we choose 2. we'd need to branch now i.e. we'd create a rhel-X.X branch at the same time the first release of OpenShift that branched using that release did and hypothetically we'd only backport things we needed to that branch.

But what would we use this branch for ? We are going to build one rhel 9.6 stream that multiple OCP releases will use.

So as you said in the first comment here, all branches (rhel 9.X, rhel 10 and dev) are going to be the same, mostly, as we still need to develop against the two majors.

Another way would be to branch when OCP move to a new Rhel Y stream. E.g branching a 9.6 when we start building 9.8.