Always generate composefs blob, don't enable runtime by default #3366
Conversation
|
Only compile tested locally so far |
There was a problem hiding this comment.
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.
That's what the code is already doing, true? https://github.com/openshift/os/pull/1700/files#diff-20b4b6908742b7029e7ed3ac70d6db47f9b9420aaf337aee712da093d1f8d129R67 |
cgwalters
force-pushed
the
unconditional-cfs
branch
2 times, most recently
from
43a8d2b to
95b13de
Compare
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]>
cgwalters
force-pushed
the
unconditional-cfs
branch
from
95b13de to
20ff086
Compare
Yes, we're currently editing it but we used to delete it. Mostly saying I guess we won't revert once we're ready to turn it back on but rather tweak it. |
Followup to 9a0acd7
Basically our composefs enablement flag has long had a tension between trying to do two things:
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:
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.