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

Always generate composefs blob, don't enable runtime by default #3366

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cgwalters
Copy link
Member

Followup to 9a0acd7

Basically our composefs enablement flag has long had a tension between trying to do two things:

  • Enable generating the composefs blob (at deployment time)
  • Enable at runtime in prepare-root

And we've hit issues in "ratcheting" enabling composefs across upgrades because of this.

This change builds on the previous one, and now it's really simple to talk about:

  • If composefs is enabled at build time, we always generate a composefs blob at deplyment time
  • Configuring the prepare-root config now mostly only affects the runtime state.

There is one detail though: in order to handle the verity requirement at deploy time, we do still parse the config then.

But for the basic "is composefs enabled at all at runtime" that is now fully keyed off the config, not the build time or (worse) whether the deployment happened to have a composefs blob.

For users who want composefs on, they need to do so in the base image configuration.

@cgwalters
Copy link
Member Author

Only compile tested locally so far

Copy link
Member

@travier travier left a comment

Choose a reason for hiding this comment

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

LGTM for the goal. Not tested/fully reviewed the code change yet.

Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

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

Hmm, I think this breaks openshift/os#1678 again, which was the primary motivation for #3353.

Well no, I guess it's fine. Previously, we'd delete the composefs enablement config file to rely on the maybe default. Now, I think we'd have to do an explicit sed to change from true to maybe, which seems cleaner anyway.

Anyway, LGTM overall.

docs/composefs.md Show resolved Hide resolved
@cgwalters
Copy link
Member Author

Hmm, I think this breaks openshift/os#1678 again, which was the primary motivation for #3353.
Well no, I guess it's fine. Previously, we'd delete the composefs enablement config file to rely on the maybe default. Now, I think we'd have to do an explicit sed to change from true to maybe, which seems cleaner anyway.

That's what the code is already doing, true? https://github.com/openshift/os/pull/1700/files#diff-20b4b6908742b7029e7ed3ac70d6db47f9b9420aaf337aee712da093d1f8d129R67

Followup to ostreedev@9a0acd7

Basically our composefs enablement flag has long had a tension between
trying to do two things:

- Enable generating the composefs blob (at deployment time)
- Enable at runtime in prepare-root

And we've hit issues in "ratcheting" enabling composefs
across upgrades because of this.

This change builds on the previous one, and now it's really
simple to talk about:

- If composefs is enabled at build time, we *always*
  generate a composefs blob at deplyment time
- Configuring the prepare-root config now mostly
  only affects the runtime state.

There is one detail though: in order to handle the
verity requirement at deploy time, we do still parse
the config then.

But for the basic "is composefs enabled at all at runtime"
that is now fully keyed off the config, not the build time
or (worse) whether the deployment happened to have a composefs
blob.

For users who want composefs on, they need to do so in the base
image configuration.

Signed-off-by: Colin Walters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants