-
Notifications
You must be signed in to change notification settings - Fork 34
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
[RFE] Handle configuration updates in /etc #647
[RFE] Handle configuration updates in /etc #647
Comments
The initial plan could be:
|
On Phase 1: I'm a bit confused about the packages and their tmpfiles directives. I would say that instead of using systemd-tmpfiles in the new service unit we could look at what is in On Phase 2: We can start with a simplified version that be able to remove files and check if they are changed or not so that they get a fresher copy from the new "/usr". For that I would copy |
I'd say that
is basically what systemd-tmpfiles is doing with our tmpfiles already, so I'd leverage it as long as we could until we get to the phase 2 where we drop it. And about:
Instead of doing it, I'd reuse what we already have. So at this point we can just slightly modify them instead of doing all the work again. Basically the point of phase 1 would be not to change the outcome, but prepare for the phase 2 and also start simplifying the ebuilds.
Yeah, I wanted to do in in second phase to avoid changing the outcome in the phase 1.
We could do it, sure. It depends if I'll be able to find a ready-to-use solution for doing the 3-way merge. If there is one, then we could skip doing the simplified version. |
This is what I meant for phase 1 and generating the tmpfile config: This should take care of being able to use upstream ebuilds. |
This is done now through an overlayfs mount and should be part of the next major Alpha |
Currently we modify the ebuilds of the packages that are putting files into
/etc
by telling them to put them somewhere in/usr
and to installtmpfiles.d
file that will tell systemd-tmpfiles to copy those files from/usr
to/etc
or create symlinks. The reason for it is that/etc
is not updated when the OS update is performed. Instead,systemd-tmpfiles
is invoked on every boot.The plan is to allow the ebuilds to put files in
/etc
. The image building process could later move those files into/usr/flatcar-etc
. The newly-built image's/etc
would be a copy of/usr/flatcar-etc
. In case of OS update, we would want to do a three-way merge of old/usr/flatcar-etc
, new/usr/flatcar-etc
and/etc
. The merge would need to happen during boot, likely before switching root from initramfs to new sysroot.In case when we want to put some extra configuration, we can create our own package that will contain those files. In case where we do not want some config from a package to be installed, we could use
INSTALL_MASK
.The
/usr/flatcar-etc
is obviously not a name set in stone. It could be very well/usr/share/flatcar-etc
or else. Still needs to be below/usr
.What needs figuring out is a way to make current
systemd-tmpfiles
way of things to cooperate with/usr/flatcar-etc
way of things, so packages can be converted incrementally, so at some point phasing out thesystemd-tmpfiles
way of things would be a non-event.It's a part of #96.
The text was updated successfully, but these errors were encountered: