Chris's Wiki :: blog/sysadmin/MixedDirectoryVCSProblem Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/MixedDirectoryVCSProblem?atomcommentsDWiki2009-12-03T10:10:14ZRecent comments in Chris's Wiki :: blog/sysadmin/MixedDirectoryVCSProblem.From 195.26.247.141 on /blog/sysadmin/MixedDirectoryVCSProblemtag:CSpace:blog/sysadmin/MixedDirectoryVCSProblem:9b611f6795d9b2bfc521bbb4d4d66ff24092f575From 195.26.247.141<div class="wikitext"><p>One thing I was wondering is exactly what problems you've actually been having and trying to solve in this way to lead you to the original post?</p>
</div>2009-12-03T10:10:14ZFrom 195.26.247.141 on /blog/sysadmin/MixedDirectoryVCSProblemtag:CSpace:blog/sysadmin/MixedDirectoryVCSProblem:caa64c0086bc282002ed5d499fd4f9118468a397From 195.26.247.141<div class="wikitext"><p>If you can abstract things enough to generate the config files using the configuration management system then you only have to version the generation of the configs (per machine), rather than the config files themselves.</p>
<p>At worst you can template them, but this still means that you'd need different template versions when things really change between versions of the software.</p>
<p>This works for at least Apache, Bind, DHCPd and various other ones with a few Puppet recipes, and it's not too tricky to add more : <a href="http://reductivelabs.com/trac/puppet/wiki/PuppetRecipes">http://reductivelabs.com/trac/puppet/wiki/PuppetRecipes</a></p>
</div>2009-12-03T10:01:31ZBy Chris Siebenmann on /blog/sysadmin/MixedDirectoryVCSProblemtag:CSpace:blog/sysadmin/MixedDirectoryVCSProblem:fd939f5bec3146bf10de283f2f5b0063b0735927Chris Siebenmann<div class="wikitext"><p>In my view, you would have similar problems if you put all of the
configuration management system's files in the same repository.
With current VCSes, if you want separate modules you need separate
repositories and that means you need separate directories.</p>
<p>Some VCSes at least have explicit support for sub-repositories,
so you could incorporate all of these separate module repositories
into a master 'configuration system' repository and still be able
to snapshot particular moments of CM system state.</p>
<p>(Mercurial has <a href="http://mercurial.selenic.com/wiki/subrepos">subrepos</a>,
which are still considered experimental. Git has <a href="http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html">submodules</a>,
which are fully supported. SVN is of course the ancestor of all of
this, with <code>svn:external</code>.)</p>
</div>2009-12-03T05:29:43ZFrom 195.26.247.141 on /blog/sysadmin/MixedDirectoryVCSProblemtag:CSpace:blog/sysadmin/MixedDirectoryVCSProblem:e138af8b0a3b1ad517ad798d2d84bf0e7851014bFrom 195.26.247.141<div class="wikitext"><p>This is precisely the sort of problem which configuration management systems are made to solve for you -- you have the separate modules (apache, bind, whatever) and put a config for them on some remote server. Then you version that set of configs, and apply only those which are appropriate for a particular machine instance.</p>
<p>At least then you'll be able to pick which modules you get on the machine.</p>
<p>For cherry-picking, you could use tags or branches to ensure that certain machines get certain sets of the files, but that gets messier than is usually necessary (well, I've not had to do this yet, but I like to keep all the configuration-management-managed machines in sync as much as possible).</p>
</div>2009-12-02T15:59:23Z