On Wed, 2006-11-15 at 15:58 -0500, John Rouillard wrote:
> Actually you don't want a branch for each system under Config (or most
> other high level tools that handle system configuration).
I'm not sure, but I think I want branches more than I want a higher
level tool. At the moment I'm not so interested in something to
control the configurations as in being able to view the contents
and changes over any time interval and the differences from one
machine to another.
> 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.
I want to be able to make changes directly on the machines - and
allow things like normal system updates to make changes. I'd just
like to propagate them back to a common repository after the fact
in a way that makes it easy to track what those changes were. I
do this with CVS and a few files from a few machines now, but it
would be nicer to have a way that permits comparing changes between
machines more easily.
> > 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
> > branches.
>
> Yup that's the problem. You end up managing a number of individual
> systems rather than managing a configuration across systems.
That's not a problem for me. Most of my machines that are similar
actually start as complete disk image copies from a master. The parts
that are changed from that are usually for individual differences. I
just want to be able to easily see what those are and when they
were done.
> 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.
I don't want to get in a fight with RPM-based system updates or
additions by on-site people that know more about local IP addressing
and routes than a central manager might, and if I really need a major
change I can always clone the disks again.
> However this is getting of topic for this list and is much more suited
> for a list like: config-mgmt at lopsa.org.
I'm not so sure. What I really want is to track a bunch of similar
versions of files which seems like something a version control system
should be good at. The trick is to get them into the system in a
way that maintains the concept of a starting point that the branches
are copied from. I suppose at the expense of 2 extra copies of the
/etc tree on each server I could start with a working copy of the master
as cloned, then script something to copy to a branch when the hostname
is changed and periodically copy in current files and commit them.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 20:38:37 2006