Bug 1691660: pkg/controller: always use the OSImageURL from the CVO

[runcom]

Signed-off-by: Antonio Murdaca [email protected]

- What I did

Always use the osimageurl coming from the CVO.

close #465

- How to verify it

Added a unit test to cover this change

- Description for the changelog

[runcom]

/retest

[kikisdeliveryservice]

Taking a look at this, there've been a couple PRs that change the render/controller config functions so refamiliarizing myself.

[cgwalters]

/approve
I like the idea though am uncertain about landing this right now given the testing we've done with the existing implementation. But it looks generally good to me.

[runcom]

I'm uncertain about landing this as well, but w/o this (assuming it works and I can add e2e) customers and users will be able to upgrade/downgrade the baseos through MCs which id love to avoid

[kikisdeliveryservice]

q: are we sure we don't want to allow this at all? just wondering before we go to the trouble of landing this and then having it reversed..

that said, i think this should be held until later when the os upgrades are healthy generally.

[runcom]

q: are we sure we don't want to allow this at all?

I don't see any real value in allowing them doing something like that, we want to control upgrades (generally) through CVO, i've always seen osimageurl in the MCs like something for testing for now, but if you all see a value in allowing users doing this, yeah, let's defer (though, do we provide them with oscontainers? will they have access to the registry containing those?

[runcom]

This has become more relevant in some hours as upgrades should follow the pattern where master are always upgraded before workers...we can play and check what users pass us of course and compare between pools but I feel the cleanest way to do it is to just forbid osimageurl altogether

[runcom]

question now is, since #480, do we want to go out with the possibility for users to do this #183 (comment) and then break them?

[LorbusChris]

nit: what is provided

[runcom]

removing WIP here, up for further discussion as I do really feel we shouldn't really expose this

[runcom]

The development flow that this might break could be handled through #496 overriding machine-os-content directly (even if you can't really control the pool, but hey, we want #480 anyway)

[cgwalters]

I think my vote on this is to land tests for OS updates first. The code here looks reasonable but it's also a nontrivial change; we know today that oc adm upgrade works. The problem is that doing testing here nicely depends on #496

[cgwalters]

removing WIP here, up for further discussion as I do really feel we shouldn't really expose this

I understand that but on the other hand...an admin really has to jump through hoops today to actually override osImageURL.

[runcom]

I think my vote on this is to land tests for OS updates first.

I'm super ok with this of course

[cgwalters]

One thing I think we could envision now potentially is adding a new custommachineconfig CRD or so that is like machineconfig but for users...and wouldn't have osImageURL.

Or alternatively, move our rendered ones into a new renderedmachineconfig CRD?

[runcom]

The second option sounds very reasonable to me :) (having a rendered MC CRD)

[runcom]

Related to https://bugzilla.redhat.com/show_bug.cgi?id=1691660 now.
Not sure how many users are now using osimageurl directly in machineconfigs, now that upgrades are generally working fine.
The related Bugzilla just highlights a flaw where if we have an user provided MC with osimageurl, then we don't respect the machineoscontent from the payload, which is wrong. I don't think there's a nice way to still honor the payload while leaving an osimageurl MC around so probably the time to just get rid of it.

This PR should land to also prevent QE test upgrades through osImageURL which is: unexpected and unsupported IMO. QE should test by creating a payload overriding machine-os-content and that should be it. Testing with osImageURL isn't real testing, just excercising a code that is excercised correctly through a normal upgrade test.

I'd also add that it would be safer to go out w/o allowing osimageurl and then, if we change design or our mind allowing it.

[runcom]

This is rebased now and ready to go!

[runcom]

/retest

[runcom]

/retest

[runcom]

/retest

[runcom]

/retest

[cgwalters]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, runcom

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cgwalters,runcom]

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