Bug 1879099: Inject version into controllerconfig, refuse mismatches #2206
Conversation
openshift-ci-robot
added
the
approved
cgwalters
force-pushed
the
render-version-check2
branch
from
dc989ec
to
9c11dd0
Compare
|
This is an alternative to #2112 that uses an annotation |
|
So in this code I didn't actually adjust the version in the bootstrap path because that requires special casing the controllerconfig rendering there, and I'm not 100% sure it's required. (If it's not I'll delete the first hunk too) |
|
hm, I did try using this on 4.5, and I get: |
cgwalters
force-pushed
the
render-version-check2
branch
from
9c11dd0
to
11349bc
Compare
|
OK tried to fix the bootstrap |
cgwalters
force-pushed
the
render-version-check2
branch
2 times, most recently
from
8c2e3fa
to
952c3a3
Compare
|
OK e2e-aws got a cluster up, this only failed on some test flakes. |
cgwalters
changed the title
openshift-ci-robot
added
bugzilla/severity-high
|
@cgwalters: This pull request references Bugzilla bug 1879099, which is valid. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test e2e-gcp-op |
|
/retest |
Should fix: https://bugzilla.redhat.com/show_bug.cgi?id=1879099 Basically we only want to roll out new machineconfigs if the controllerconfig (generated by the operator) and the controller are at matching versions. Per Jerry's comment in Bugzilla: > 1. The new MCO rolls out. It first syncs the controllerconfig to the new one as part of the RenderConfig step above. > 2. The running (old) MCC's template controller has an informer on the controllerconfig, which since the previous step updated the config, calls a syncControllerConfig. This re-generates the base master config (00-master MC) > 3. The running (old) MCC now sees a MC change which calls another sync call to generate a new rendered config, and instructs the master pool to start an update > 4. The new MCC rolls out, and does the whole rendering process, creating the actual updated MC for the master pool, which it waits until the previous one is finished, and starts the new (real) update. After this patch, the old MCC will refuse to render from a controllerconfig generated by the new MCO.
cgwalters
force-pushed
the
render-version-check2
branch
from
952c3a3
to
60c5ee2
Compare
|
/approve |
|
[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:
Approvers can indicate their approval by writing |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
@cgwalters: All pull requests linked via external trackers have merged: Bugzilla bug 1879099 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@cgwalters: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/cherrypick release-4.6 |
|
@cgwalters: new pull request created: #2257 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Should fix: https://bugzilla.redhat.com/show_bug.cgi?id=1879099
Basically we only want to roll out new machineconfigs if
the controllerconfig (generated by the operator) and the
controller are at matching versions.
Per Jerry's comment in Bugzilla:
After this patch, the old MCC will refuse to render from a controllerconfig generated by the new MCO.