docs/filesystem: Rework state overlay and /opt messaging a bit
#1199
Conversation
Tweak the changes in bootc-dev#1191 to more clearly lay out the tradeoffs of state overlays. Contrast it with transient root (since that was one of the primary motivations for it), and generalize the "alternatives" to be about both approaches.
github-actions
bot
added
documentation
|
|
||
| The disadvantages are: | ||
| - There is no equivalent to this feature in the Docker/Podman ecosystem. | ||
| - It allows for some temporary state drift until the next update. |
There was a problem hiding this comment.
I'm fine with this as written but I think the thing that specifically bothers me is it feels quite subtle that that persistence is the default for unknown files, but we overwrite known files while both are mutable. That semantic is absolutely closer to "just works" for many cases of course...
Maybe in reality it's not a real problem.
Maybe what would help is if we offered a clear tooling to show you the diff and help you flush any unwanted files? Not sure.
There was a problem hiding this comment.
I guess maybe I'm objecting to the "state drift until the next update" because in the case you accidentally write something there you will get that drift.
There was a problem hiding this comment.
it feels quite subtle that that persistence is the default for unknown files, but we overwrite known files while both are mutable
Though note that's basically the same semantics as RPM for non-config files. Hmm, would it help the mental model to add that to the docs?
Maybe what would help is if we offered a clear tooling to show you the diff and help you flush any unwanted files? Not sure.
Yeah, that'd definitely be useful. I guess for now find /var/ostree/state-overlays/$name/upper is close to that.
I guess maybe I'm objecting to the "state drift until the next update" because in the case you accidentally write something there you will get that drift.
Hmm, don't quite follow this. If you overwrite something that's owned by the RPM, it will get reconciled in the next update (so temporary drift). Writing anywhere else under the overlay is assumed to be state, just like /var is state. So calling that "state drift" feels odd to me.
Tweak the changes in #1191 to more clearly lay out the tradeoffs of state overlays. Contrast it with transient root (since that was one of the primary motivations for it), and generalize the "alternatives" to be about both approaches.