On Tue, Nov 14, 2006 at 03:01:38PM -0600, Les Mikesell wrote:
> On Tue, 2006-11-14 at 12:21 -0500, John Rouillard wrote:
> > In my case I have to cherry pick files at different revisions into a
> > single tag all the time because the files are loosely coupled but
> > deployed as a single entity (system configuration) but I currently
> > have 40 or so subsets of files that are totally independent. So I get
> > revision 1026 of the ssh keys files, revision 223 of the ssh config
> > files, revision 2230 of the ldap config files etc.
> I think what you really want is to maintain the systems as branches
> in the first place,
Actually you don't want a branch for each system under Config (or most
other high level tools that handle system configuration).
Config was designed to utilize templates driven from a "database"
description of the configuration of the system. So you never check in
a file for a host but for a class of host. E.G. external ssh server or
internal ssh server, ldap server for a given site etc. The file for
the host is a generated item not a primary version controlled item.
It is less about managing a single system and more amount managing a
constellation of systems based on what they are doing. I can change
services from one box to another by modifying the database and
re-distributing the result of applying the database to the files in
> but I haven't come up with a way to import
> things in a way that gives them a common parent and maintains the
> common base versions on a trunk with only the differences in the
Yup that's the problem. You end up managing a number of individual
systems rather than managing a configuration across systems.
> Has anyone worked out a scheme for this where the
> (slightly) differing versions already exist as a starting point,
> then ongoing changes are made in one of the branches and may or
> may not be propagated to the trunk and other branches? I'd love
> to be able to 'svn diff' all or any configs from one machine to
> another as well as different timeframes.
Well you can create makefiles/scripts that control propagation of
changes/diffs but I think you are going in the wrong direction. IMO
you need to be looking at creating master templates, controlling those
and generating from the templates the individual configs for the
hosts. Trying to go the other way is much more difficult.
However this is getting of topic for this list and is much more suited
for a list like: config-mgmt at lopsa.org.
603-643-9300 x 111
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 15 21:59:51 2006