Re: [gentoo-soc] Configuration managment system

[Fabian Groffen]

Hi Jonas,

First, I think this is an interesting approach, especially because it
tries to be more than just /etc in $VCS, IMO.

Some general remarks, /etc should be what's in CONFIG_PROTECT, which can
be multiple locations IIRC.  Next, I'd prefer the proposal to be mildly
VCS agnostic.  I for one can much easier mess around with CVS and SVN,
then with bzr, git, hg, etc.  Just a bit of taste.

I'm going to cut some huge parts from your mail, and respond ;)

On 26-03-2009 03:11:54 +0100, Jonas Bernoulli wrote:
> For various reasons "etc-under-version-control" loses much of the
> power and/or ease of use that comes with the underlying vcs. Much of
> this being due to the fact that the files being kept in the repository
> are totally unrelated.

I think Jeremy already hinted at this, you probably should try to
make your point somewhat stronger here.  Maybe "conceptual cleanness",
and the benefits you get with that e.g. when removing a package (and
it's config files!) will give you a convincing story.

> The solution to this obviously is to maintain a separate branch for
> each package. And just as obvious one big problem is that the config
> files of most applications are mangled into the same location namely
> /etc (and elsewhere) making hard to impossible to use normal vc
> commands related to branches.

A branch, or maybe just separate modules?  Like you said, it's totally
unrelated, so why would it be in the same module?

> To those not familiar with git what this basically does is to checkout
> the branch containing the live files of $package without removing any
> files that are not part of the branch - it's faking a checkout without
> actually performing one.  It's a bit more complex than that but this
> is what basically has to be done since we can not remove files not
> belonging to a package from /etc. We are on a live system after all
> and these files might be required while we configure $package.

Just toying with some thoughts here.  Suppose that /etc is a "read-only"
export of your vcs contents somehow.  One could say that all known (and
active?) modules are exported into some some clean image, and then that
image is made active in /etc (removing stuff that is not in the image,
e.g. rsync -a --delete).
How this image is generated can be using your GIT thing, or some other
approach that would work fine with multiple CVS/SVN modules.
The important part, is that you can somehow enter a virtual
chroot/sandbox with just the configuration files of package X, where you
have VCS stuff, such that you can do whatever you need to do.

> So one could simply write a shell script that extends the above mockup
> to be run before and after work on the config files of $package.
> While this would be an improvement over etc-under-vc it is still very
> impractial to use.

Portage would indeed "mount" the same sandbox, and commit any changes.
One can think about branches or tags, which IMO is VCS and user
specific.  Some people might like to have separate branches (one with
vanilla stuff committed by Portage, the other with their own changes).

> After the files are copied to the live system and if there are no
> conflicts git can not resolve (there will be less conflicts than
> currently) the 'vanilla' branch is merged into the 'live' branch.

Is this an automatic merge of a branch into another branch, or is this
an update of a modified working copy?  Just to be sure, I think if you
have a VCS at hand anyway, you want to commit your config files to it ;)

> If on the other hand automatic merging is not possible for all files
> then only the conflict-free files are copied to the live system and
> the package is added to a list of packages that have to be later
> merged.

Question, should this happen automatically at all?  If you made no
changes to a config file, no conflicts will happen.  If you did made
some changes, maybe you better wait for the user to review them.
Probably a three-way option here to match the user's preferences.

Example why automatic merging (without conflicts) that is not desirable:

 #
+# wipe / on every boot
+rm -Rf /
 #

ok, made up, but some people might not like cleaning /tmp on boot.

> This tool won't be limited to the task of replacing etc-update.  It is
> also used to commit changes to configuration files made during daily
> use.  It should also support many of the operations that the
> underlying git supports while providing something like the above
> mockup split in the two obvious parts so that git can be used directly
> in hairy cases. This tool should feature an  expert (plumbing) mode as
> well as a simple (porcelain) mode suitable for people not willing to
> learn about git. Generally the interface will be similar to that of
> git.

I think this would be easier to achieve when you say the target (/etc)
is read-only, and just regenerated upon every commit to any of the
packages that you "edit" through confsync.

> Not only does above description not contain all relevant details it
> also does not list most benefits that confsink offers. For one,
> confsink would allow easier sharing of configuration between multiple
> machines and even users.

That's an extension that probably should be stressed a bit more, as it
would allow for clusters to solve the problem when updating package X
(from binpkg) still results in config files not being changed
appropriately.  Tools like puppet can help in setting config files here,
but what is nicer than a system where upgrading a package immediately
gets the proper configuration from the master?


-- 
Fabian Groffen
Gentoo on a different level