-
Notifications
You must be signed in to change notification settings - Fork 273
Open
Labels
jirafor syncing to jirafor syncing to jira
Description
Marking an experimental spec as stable
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:
Making the experimental package stable
- 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.
Creating the new experimental package
- 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.
Update all relevant places to use the new experimental package
- 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
Update the blackbox tests
- 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 docs
- 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.
External tests
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.
Other packages
- 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.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
jirafor syncing to jirafor syncing to jira