| name | Stabilization checklist |
|---|---|
| about | Stabilization checklist template |
| title | New stabilization for ignition |
| labels | jira |
When an experimental version of the Ignition config spec (e.g.: 3.1.0-experimental) is to be declared stable (e.g. 3.1.0), there are a handful of changes that must be made to the code base. These changes should have the following effects:
- Any configs with a
versionfield set to the previously experimental version will no longer pass validation. For example, if3.1.0-experimentalis being marked as stable, any configs written for3.1.0-experimentalshould have their version fields changed to3.1.0, for Ignition will no longer accept them. - A new experimental spec version will be created. For example, if
3.1.0-experimentalis being marked as stable, a new version of3.2.0-experimental(or4.0.0-experimentalif backwards incompatible changes are being made) will now be accepted, and start to accumulate new changes to the spec. - The new stable spec and the new experimental spec will be identical except for the accepted versions. The new experimental spec is a direct copy of the old experimental spec, and no new changes to the spec have been made yet, so initially the two specs will have the same fields and semantics.
- The HTTP
Acceptheader that Ignition uses whenever fetching a config will be updated to advertise the new stable spec. - New features will be documented in the Upgrading Configs documentation.
The changes that are required to achieve these effects are typically the following:
- Rename
config/vX_Y_experimentaltoconfig/vX_Y, and update the golangpackagestatements - Drop
_experimentalfrom all imports inconfig/vX_Y - Update
MaxVersioninconfig/vX_Y/types/config.goto delete thePreReleasefield - Update
config/vX_Y/config.goto update the comment block onParseCompatibleVersion - Update
config/vX_Y/config_test.goto test that the new stable version is valid and the old experimental version is invalid - Update the
Acceptheader ininternal/resource/url.goto specify the new spec version.
- Copy
config/vX_Yintoconfig/vX_(Y+1)_experimental, and update the golangpackagestatements - Update all
config/vX_Yimports inconfig/vX_(Y+1)_experimentaltoconfig/vX_(Y+1)_experimental - Update
config/vX_(Y+1)_experimental/types/config.goto setMaxVersionto the correct major/minor versions withPreReleaseset to"experimental" - Update
config/vX_(Y+1)_experimental/config.goto point theprevimport to the new stablevX_Ypackage and update the comment block onParseCompatibleVersion - Update
config/vX_(Y+1)_experimental/config_test.goto test that the new stable version is invalid and the new experimental version is valid - Update
config/vX_(Y+1)_experimental/translate/translate.goto translate from the previous stable version. Update theold_typesimport, delete all functions excepttranslateIgnitionandTranslate, and ensuretranslateIgnitiontranslates the entireIgnitionstruct. - Update
config/vX_(Y+1)_experimental/translate/translate_test.goto point theoldimport to the new stablevX_Y/typespackage - Update
config/config.goimports to point to the experimental version. - Update
config/config_test.goto add the new experimental version toTestConfigStructure. - Update
generateto generate the new stable and experimental versions.
- All places that imported
config/vX_Y_experimentalshould be updated toconfig/vX_(Y+1)_experimental. - Update
tests/register/register.goin the following ways:- Add import
config/vX_Y/types - Update import
config/vX_Y_experimental/typestoconfig/vX_(Y+1)_experimental/types - Add
config/vX_Y/types's identifier toconfigVersionsinRegister()
- Add import
- Bump the invalid
-experimentalversion in the relevantVersionOnlyConfigtest intests/negative/general/config.go. - Find all tests using
X.Y.0-experimentaland alter them to useX.Y.0. - Update the
Acceptheader checks intests/servers/servers.goto specify the new spec version.
- Update
internal/doc/main.goto add the new stable spec and reference the new experimental spec ingenerate(). - Run
generateto regenerate Go schemas and spec docs. - Add a section to
docs/migrating-configs.md. - In
docs/specs.md, update the list of stable and experimental spec versions (listing the latest stable release first) and update the table listing the Ignition release where a spec has been marked as stable. - Note the stabilization in
docs/release-notes.md, following the format of previous stabilizations. Drop the-expversion suffix from any notes for the upcoming release.
If there are any external kola tests that are not part of the Ignition repo (e.g. tests in the fedora-coreos-config repo) that use the now-stabilized experimental spec or the corresponding soon-to-be-stabilized Butane spec, CI will fail for the spec stabilization PR.
- Uncomment the commented-out workarounds in
.cci.jenkinsfile. - When bumping the Ignition package in fedora-coreos-config, you'll need to remove
-experimentalfrom affected Ignition and Butane configs in external tests. Remove-experimentalfrom the Butane configs even though the Butane spec hasn't been stabilized yet; kola will handle it. - Comment out the workarounds.
- Add a stable spec to ignition-config-rs and regenerate schema.
- Put out a new release.
- Bump ignition-config-rs in coreos-installer to support the new spec in
iso customizeandpxe customize. Update release notes.- Put out a new coreos-installer release.
- Add a new downgrade translation to ign-converter.
- Stabilize Butane specs.
- Put out a new release.
- Drop
-experimentalfrom configs in FCOS docs and remove colocated experimental-config warnings - Revendor Ignition and Butane into coreos-assembler and update
mantle/platform/conf/conf.goandconf_test.go. - Ask the Machine Config Operator to support the new spec.