New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
*: Ign spec 3 upgrade #1873
*: Ign spec 3 upgrade #1873
Conversation
pkg/controller/common/helpers.go
Outdated
} | ||
|
||
// Test: have some situations de-duplicate and see what happens, will merge into main function | ||
func ParseAndConvertConfigWithDeduplication(rawIgn []byte) (ign3types.Config, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will probably merge this into the main function, just trying to think if there's scenarios we won't want to de-duplicate
|
||
// TODO jerzhang check if you can have contents and dropins in the same file | ||
unitNameMap := map[string]bool{} | ||
var outUnits []ign2types.Unit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
return err | ||
} | ||
if needUpdate { | ||
_, err = ctrl.client.MachineconfigurationV1().MachineConfigs().Update(context.TODO(), config, metav1.UpdateOptions{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
return err | ||
|
||
switch typedConfig := ignconfigi.(type) { | ||
case ign3types.Config: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for validation I'm thinking we should keep validating in the config that it was created in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesnt the ign translator func also validate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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). |
65439a3
to
839b435
Compare
839b435
to
755255e
Compare
/test e2e-gcp-upgrade |
/test e2e-aws |
/test e2e-aws flaking on various other tests, but just to make sure... |
d85867f
to
2061677
Compare
/test e2e-openstack |
/test e2e-azure |
2435429
to
48b90df
Compare
Squashed commits and added better message |
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>
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. 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. |
/hold cancel This is ready to go
Unfortunately the CI account and my account is the same namespace I think |
/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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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