Skip to content
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

*: switch to v3.2.0 Ignition configs instead of v3.1.0 #2248

Merged
merged 2 commits into from Dec 4, 2020

Conversation

arithx
Copy link
Contributor

@arithx arithx commented Nov 23, 2020

- What I did

Switch the underlying Ignition spec 3 configs to use the 3.2.0 types (and update the underlying translation for spec 3 configs to uptranslate into 3.2.0).

- How to verify it

Spec 3 configs should remain working. Additionally new config fields that are only present in the Ignition 3.2.0 spec (see here for a list of new features to the 3.2.0 spec) can be specified.

- Description for the changelog

vendor commit: Bump ign-converter to pick up v32tov2x translation packages & pull in spec 3.2.0 Ignition packages
other commit: update the ign3types import to use the config/v3_2/types package instead of config/v3_1/types

@arithx
Copy link
Contributor Author

arithx commented Nov 23, 2020

/retest

Copy link
Member

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly concerned about the MCS parts.

If every spec bump involves this level of churn that's a bit unfortunate but, solving that seems hard without reworking the API.

@@ -283,8 +283,8 @@ func detectSpecVersionFromAcceptHeader(acceptHeader string) (*semver.Version, er

for _, header := range headers {
if header.MIMESubtype == "vnd.coreos.ignition+json" && header.SemVer != nil {
if !header.SemVer.LessThan(*v3_1) && header.SemVer.LessThan(*semver.New("4.0.0")) {
return v3_1, nil
if !header.SemVer.LessThan(*v3_2) && header.SemVer.LessThan(*semver.New("4.0.0")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In both the API and the tests we need to also continue to handle 3.1 right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yep, that was an oversight. I've got coreos/ign-converter#19 up to add v32tov31 down-translation. After that merges I'll bump the ign-converter vendor again & update to check for v3_1 semver, down-translate in server/api & add tests for 3.1.0 in server/api_test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I think I've addressed this.

I've added back support for v3_1 headers, added 3.2.0 -> 3.1.0 translation, and re-added unit tests in pkg/server/api_test.

Ignition was already bumped to version 2.7.0 but nothing was actually
referencing the v3_2 configs to pull them in.
@cgwalters
Copy link
Member

/approve

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 24, 2020
@cgwalters
Copy link
Member

Hmm not sure what went wrong with that e2e-aws run; installer ran fine but then this failed which seems like something in CI glue:

2020/11/23 23:11:26 Failed to upload $KUBECONFIG: timed out waiting for the condition

@arithx
Copy link
Contributor Author

arithx commented Nov 24, 2020

/retest

1 similar comment
@arithx
Copy link
Contributor Author

arithx commented Nov 24, 2020

/retest

@kikisdeliveryservice
Copy link
Contributor

throwing a hold while i review

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 24, 2020
@kikisdeliveryservice
Copy link
Contributor

Also okd-e2e is currently red and it looks like rhel7 is flaky, so you don't have to retest @arithx ill confirm we can skip the rhel7 one and deal with that later.

@darkmuggle
Copy link
Contributor

@kikisdeliveryservice in light of your hold, have you had a chance to review?

The update to spec is needed for finalizing complex disks (confirmed by @bgilbert via Slack)

I looked over the code, and nothing stands out.
/approve

@darkmuggle
Copy link
Contributor

/retest

@kikisdeliveryservice
Copy link
Contributor

I believe @yuqi-zhang is looking it over too, wanted to give MCO team the opp to review this as it's non-trivial.

@ashcrow
Copy link
Member

ashcrow commented Dec 2, 2020

@yuqi-zhang PTAL

@yuqi-zhang
Copy link
Contributor

Did some testing for this, upgraded fine, and all generated configs are on 3.2, applied 2.2 config looks fine, scaling node looks fine

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Dec 2, 2020
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arithx, cgwalters, darkmuggle, 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:
  • OWNERS [cgwalters,yuqi-zhang]

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

@yuqi-zhang
Copy link
Contributor

Will let @kikisdeliveryservice cancel the hold when comfortable

@kikisdeliveryservice
Copy link
Contributor

will lift hold once jerry's q above is addressed.

@kikisdeliveryservice
Copy link
Contributor

Q as a consumer of ignition : are you planning on chaining parsers? bc as you can see moving forward with future versions this is going to cause a mess...

@kikisdeliveryservice
Copy link
Contributor

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Dec 2, 2020
@bgilbert
Copy link
Contributor

bgilbert commented Dec 2, 2020

@kikisdeliveryservice We chained parsers in spec 2.x but removed that functionality for spec 3. I agree that we should think about adding it back.

@bgilbert
Copy link
Contributor

bgilbert commented Dec 3, 2020

/retest

1 similar comment
@bgilbert
Copy link
Contributor

bgilbert commented Dec 3, 2020

/retest

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

2 similar comments
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@kikisdeliveryservice
Copy link
Contributor

this is fully approved and made the deadline, e2e is still hitting some well documented ci resource issues:

   * could not run steps: step e2e-agnostic-upgrade failed: failed to acquire lease: resources not found
time="2020-12-03T17:10:30Z" level=info msg="Reporting job state 'failed' with reason 'executing_graph:step_failed:utilizing_lease'" 

which are still being worked on by admins...

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

4 similar comments
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants