*: Ign spec 3 upgrade#1873
Conversation
openshift-ci-robot
added
do-not-merge/work-in-progress
openshift-ci-robot
added
the
approved
yuqi-zhang
requested review from
LorbusChris and
runcom
and removed request for
mtrmac and
umohnani8
There was a problem hiding this comment.
will probably merge this into the main function, just trying to think if there's scenarios we won't want to de-duplicate
There was a problem hiding this comment.
so units is somewhat wonky since it needs to consider dropins when doing a merge, now consider this scenario:
Unit A:
Content: AC
Dropins:
Dropin: AD
Unit B:
Content: BC
Dropins:
Dropin: BD
Should the final look like:
Unit rendered:
Content: BC
Dropins:
Dropin: AD
Dropin: BD
or
Unit rendered:
Content: BC
Dropins:
Dropin: BD
There was a problem hiding this comment.
I'd be in favor of the former, having both drop ins added.
Another case that may also be considered is if there is a unit in one template, and a dropin only in another template.
There was a problem hiding this comment.
In the case of a unit in one and a dropin in another, both the existing spec 2 behaviour and the ignition spec 3 merge function keeps both, so I think we should keep that.
And agreed, having both dropins probably makes it more consistent
There was a problem hiding this comment.
For non-rendered configs I probably need a better location to update them, there is also the Boostrap path to consider
There was a problem hiding this comment.
that said with this update in place we will no longer be able to rollback, so maybe for user-created configs I should keep it in the version that it was on?
There was a problem hiding this comment.
for validation I'm thinking we should keep validating in the config that it was created in
There was a problem hiding this comment.
doesnt the ign translator func also validate?
There was a problem hiding this comment.
Right in this case I meant validating the on-disk config based on the rendered-config
If the cluster is still on a spec 2 rendered-config version (which shouldn't happen that often, only should happen if a) templates changed causing a race or b) a rendered-config was created during a middle of an update or c) a previous rendered-config update was failing), I'm thinking we should continue to validate in spec 2, instead of translating up and then validating in spec 3.
Maybe we could get away with translating first, just have to be a bit more careful
|
With #1766 rebased this also works on first installs (take a 4.6 installer and override release image with this MCO), which brings up everything in spec 3 automatically. Next steps:
|
|
@yuqi-zhang I'll leave #1778 open for now, as it might be helpful as a reference. The upgrade path isn't handled there yet, because there is no deduplication of units happening (we'll probably also want this for files). |
yuqi-zhang
force-pushed
the
ign-spec-3-upgrade
branch
from
65439a3 to
839b435
Compare
openshift-ci-robot
removed
the
needs-rebase
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
yuqi-zhang
force-pushed
the
ign-spec-3-upgrade
branch
from
839b435 to
755255e
Compare
|
/test e2e-gcp-upgrade |
|
/test e2e-aws |
|
/test e2e-aws flaking on various other tests, but just to make sure... |
yuqi-zhang
force-pushed
the
ign-spec-3-upgrade
branch
from
d85867f to
2061677
Compare
|
/test e2e-openstack |
|
/test e2e-azure |
yuqi-zhang
force-pushed
the
ign-spec-3-upgrade
branch
from
2435429 to
48b90df
Compare
|
Squashed commits and added better message |
yuqi-zhang
force-pushed
the
ign-spec-3-upgrade
branch
from
48b90df to
fc052b2
Compare
|
/test e2e-vsphere |
|
I don't expect any of those tests to pass except azure we're out of quota, and the other ones we haven't passed in awhile. |
|
/lgtm |
|
|
|
/test e2e-ovirt |
|
/test e2e-gcp-upgrade |
Can you run the e2e-azure test on your own azure cluster? or is quota gone for everything? |
|
now that #1792 has merged, does this need an update to switch the pointer config to v3 as well? |
This is the commit that aims to upgrade the spec version used in the MCO from ignition spec 2 to spec 3. With this change in place: - New clusters will have all machineconfigs in spec 3, minus those created by the installer. - Existing clusters will re-render templates into spec 3 upon an upgrade, and render all rendered-machineconfigs into spec 3 with translation from spec 2. Existing rendered-configs and user-created configs will not be translated in-place, but rather re-translated anytime rendering happens. All clusters from this point on will support new MCs with ignition on spec 2 or spec 3. Other key points of this PR: - A de-duplication function is added, so spec 2 -> spec 3 translation can happen. This should not change existing behaviour. A unit test is added to show the expected outcome. - The FCCT usage is slightly modified to account for duplication. Eventually we should use TranslateBytes() from FCCT to get verification. - Validation of on-disk state will still be parsed in the ignition spec version the rendered-config was created in. All other locations translate the config from spec 2 to spec 3 (e.g. Reconcilable). Signed-off-by: Yu Qi Zhang <jerzhang@redhat.com>
This will allow us to manage a secret to scale up nodes with ignition v2 binary installed. Signed-off-by: Yu Qi Zhang <jerzhang@redhat.com>
yuqi-zhang
force-pushed
the
ign-spec-3-upgrade
branch
from
fc052b2 to
22b8b24
Compare
|
Rebased again and modified stub secret generation to v3 |
|
@yuqi-zhang: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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. |
|
/hold cancel This is ready to go
Unfortunately the CI account and my account is the same namespace I think |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/retest |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: runcom, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
6 participants
Based on #1703, this is a (messy and hacky) MCO that renders all existing configs to spec 3. Currently tested to work with a default install upgrading to this.
Unit and e2e tests not included