feat: add z-stream upgrade configuration support via static Helm values

[machi1990]

What

feat: add z-stream upgrade configuration support via static Helm values

Why

Add support for configuring z-stream upgrade for OCP minor versions using static Helm values files

This follows up the #3832 (comment) by implementing the first option to workaround limits with deployment pipelines:

• 64 variable limit
• inability to load complex data from config.yaml similar to what's done in 75a0661

Special notes for your reviewer

Likely superseding #3832 for now and opened as a base for discussion

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: machi1990
Once this PR has been reviewed and has the lgtm label, please assign janboll for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• cluster-service/OWNERS
• config/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[stevekuznetsov]

Really seems like the backend should be in charge of this and CS should just accept an explicit, opaque value to install and deal with it. Why are we adding more logic to CS for this when we're just going to have to migrate it later?

[machi1990]

Really seems like the backend should be in charge of this and CS should just accept an explicit, opaque value to install and deal with it.

I agree. However...

Why are we adding more logic to CS for this when we're just going to have to migrate it later?

By the time the decision to move CS to the RP, some features were already at work (in progress) and this was one of them. At that time, it was agreed (with leadership) that we'll continue to work on those features as is in CS and when the migration is fully ongoing, we'll migrate everything including new code. The motivation for this message was so that the migration doesn't slow feature development.

cc @davidffrench @deads2k to chime in for additional insights

[davidffrench]

+1 to @machi1990 comment, the implementation was already in progress. I would like us to ensure successful delivery of managed z stream upgrades as early as possible

[stevekuznetsov]

when the migration is fully ongoing, we'll migrate everything including new code

I see a good half-dozen open PRs by Miguel in this repo right now - by what metric is the migration not fully ongoing?

[davidffrench]

We should continue to ask everytime if it something should be added to CS or the backend directly, as time passes, the answer will increasingly become more weighted to the RP.

I see a good half-dozen open PRs by Miguel in this repo right now - by what metric is the migration not fully ongoing?

You are correct. A different phrasing of Manyandas comment is that we decided to implement this functionality in CS when it started in December as it would allow us to support this in production the fastest, and this logic in CS will be a part of the migration effort over the coming months.