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

Make experimental spec stabilization smoother #451

Closed
jlebon opened this issue Apr 3, 2023 · 3 comments · Fixed by coreos/coreos-assembler#3422
Closed

Make experimental spec stabilization smoother #451

jlebon opened this issue Apr 3, 2023 · 3 comments · Fixed by coreos/coreos-assembler#3422
Labels

Comments

@jlebon
Copy link
Member

jlebon commented Apr 3, 2023

In the latest 1.5.0 stabilization, there were a lot of churn across multiple repos (at least this one, https://github.com/coreos/coreos-assembler, https://github.com/coreos/fedora-coreos-config, and https://github.com/openshift/os) and branches within these repos that required tweaking because we had tests that used the 1.5.0-experimental spec.

What are some ways we could make stabilization smoother in the future?

@jlebon
Copy link
Member Author

jlebon commented Apr 3, 2023

One crude idea is to have some kind of hidden BUTANE_UNSUPPORTED_ALLOW_EXPERIMENTAL env var knob where 1.5.0-experimental could be parsed as if it were 1.5.0 temporarily to increase the window of time available for transition.

@bgilbert
Copy link
Contributor

The main issue is the Ignition/Butane ratchet, which was unusually protracted this time, and the inability to revendor Ignition into cosa without also updating Butane. coreos/coreos-assembler#3422 should remove the cosa codebase from the critical part of that ratchet, so that the process will just require updating tests in fedora-coreos-config and openshift/os.

AIUI there was another issue this cycle, where some RHCOS 4.13 CI was running on cosa main and some was running on rhcos-4.13. The cosa PR should prevent that from causing an issue, though of course we should also try not to do it.

@bgilbert
Copy link
Contributor

Checklist update in coreos/ignition#1607.

bgilbert added a commit to coreos/coreos-assembler that referenced this issue Apr 13, 2023
There are three stabilization cases we need to handle:

1. Tests using an experimental Ignition spec that's being stabilized.
2. Tests using an experimental Butane spec that's being stabilized, where
   the Butane spec already produces a stable Ignition spec.
3. Tests using an experimental Butane spec that's being stabilized, where
   the Butane spec produces an Ignition spec which is also being
   stabilized.

We already have a procedure for case 1.  Ignition configs in tests are
stabilized by the PR that lands the new Ignition in
fedora-coreos-config, and mantle has code to detect the next stable
Ignition spec (otherwise unparsable) and wrap it in an older spec
version that mantle does know how to handle.  This is good enough for
Ignition in the image, and avoids requiring immediate revendoring of
the new Ignition into mantle.

Implement a similar approach for cases 2 and 3.  Butane configs in
tests can be stabilized by the PR that updates Ignition in the image.
When we see a Butane config with an unrecognized variant/version pair,
try stapling "-experimental" onto the spec version and see if we can
parse the config.  That's sufficient for case 2, but case 3 has the
additional complication that Butane's output will no longer be accepted
by Ignition in the image.  Handle that by stripping "-experimental"
from the Ignition config version.  (Parsing the result will succeed
because of the case 1 workaround.)

As a result, revendoring of both Ignition and Butane into mantle can be
deferred until convenient, allowing both projects to be updated
simultaneously once the new Butane release is out.  This is important
because there's generally a delay between the two releases, and the
previous Butane version will depend on API that's missing from the new
Ignition version.

Fixes coreos/butane#451.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants