-
Notifications
You must be signed in to change notification settings - Fork 247
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
Add persistence mechanism between stages; write result report to provisioned system #1250
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jul 21, 2021
jlebon
reviewed
Jul 22, 2021
Serialize a struct to a JSON file in /run at the end of each stage and load it at the beginning of the next stage. This is intended to be an internal mechanism that can change incompatibly without warning.
Record some bits of information that the distro might want to know for display purposes. This file is intended to be a reasonably stable interface for distro use.
Updated! And added the boot ID from coreos/fedora-coreos-config#1128 (comment). |
jlebon
approved these changes
Jul 22, 2021
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.
Nice work!
bgilbert
added a commit
to coreos/fedora-coreos-config
that referenced
this pull request
Aug 6, 2021
As of coreos/ignition#1250, Ignition produces its own report similar to ignition.info.json, so use that instead of making our own.
HuijingHei
pushed a commit
to HuijingHei/fedora-coreos-config
that referenced
this pull request
Oct 10, 2023
As of coreos/ignition#1250, Ignition produces its own report similar to ignition.info.json, so use that instead of making our own.
HuijingHei
pushed a commit
to HuijingHei/fedora-coreos-config
that referenced
this pull request
Oct 10, 2023
As of coreos/ignition#1250, Ignition produces its own report similar to ignition.info.json, so use that instead of making our own.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Increasingly, we need to persist small bits of state between stages. Add a general mechanism for this, which serializes a struct to a JSON file in
/run
at the end of each stage and loads it at the beginning of the next stage. For now, use the mechanism to record the fetched-config summaries that are reported to the journal, plus LUKS keyfiles for the files stage.Additionally, use this functionality to write a JSON file to
/var/lib/ignition/result.json
that contains the provisioning timestamp and a flag indicating whether a user config was used. The idea is to move this functionality upstream, allowing distros to display summary information about how provisioning went.The state mechanism is intended to be an internal API that can change without warning. The result file format is intended to be reasonably stable, but since it's easy to add compatibility hacks when writing it, I don't think we need to be overly careful when adding things to the format.
It'd be great if we could eventually use the status file to replace the structured journal entries, since the latter seems like a fairly awkward and obscure interface. It's unclear how much of a compatibility issue that would pose, though.