Re: [RFC] Union mounts/writable overlays design

[Valerie Aurora <vaurora@redhat.com>]

On Thu, Oct 01, 2009 at 03:08:46PM -0500, kevin granade wrote:
> On Thu, Oct 1, 2009 at 12:55 PM, Jan Blunck <jblunck@suse.de> wrote:
> > Am 01.10.2009 um 19:15 schrieb Valerie Aurora <vaurora@redhat.com>:
> >
> >> On Thu, Oct 01, 2009 at 10:38:27AM -0500, kevin granade wrote:
> 
> 
> >>>> Non-features
> >>>> ------------
> >>>>
> >>>> Features we do not currently plan to support as part of writable
> >>>> overlays:
> >>>>
> >>>> Online upgrade: E.g., installing software on a file system NFS
> >>>> exported to clients while the clients are still up and running.
> >>>> Allowing the read-only bottom layer to change while the writable
> >>>> overlay file system is mounted invalidates our locking strategy.
> >>>>
> >>>
> >>> So as long as the RO filesystem is NOT mounted as part of an overlay, you
> >>> could modify it and then re-construct the previous overlay and things
> >>> will
> >>> work as expected?
> >>> For example could one create a hard drive over CD overlay, then
> >>> periodically
> >>> (requiring a reboot probably) replace the underlying CD with a new
> >>> version
> >>> and automagically have new versions of software available? ?( obviously
> >>> there are additional complexities in packaging to make this work, but
> >>> having
> >>> support in the kernel is the first step. )
> >>
> >> This could theoretically work, but the main problem is resolving
> >> differences between files (always the big problem in upgrade). ?Say
> >> you have /etc/passwd, you add a new user and write to it on the top
> >> layer, and then the next upgrade adds a new user to the read-only
> >> version. ?You're not going to see the new user.
> >>
> >
> > No. Scripts that come with updated packages still need to run on the union.
> > Otherwise this is just asking for problems. Probably you could come up with
> > a clever merger if the update and the base image is still available.
> >
> 
> Yes, that sort of thing is what I meant by "additional complexities in
> packaging", and I understand that they are in no way trivial, but I
> was mostly interested in whether that kind of behavior would be
> supported at the kernel level at all.

To a first approximation, if your question looks anything like:

"Can I do [...] packaging [...] with writable overlays?"

The answer is, no, you can't, and if you could, it wouldn't have the
results you expected.

Writable overlays are to packaging as file system snapshots were to
source control - check out all the old papers, people were always
saying, "And you can use it to make an easy diff of your changes to
your source code!"  Now that we have decent source control, no one
would dream of versioning their source control with file system level
snapshots - what about commit grouping?  What about commit messages?
What about annotation?

I think packaging is at the same level today.  Seriously, go check out
Puppet before hacking around with writable overlays.  It will probably
fix your problems and give you more features.

-VAL