Configuration management vs. automated integration (was: Enterprise and Debian Pure Blends)
Breaking this up a little bit, since I seem to have written a novel in
response to the first part of your message. :)
"Jesús M. Navarro" <jesus.navarro@undominio.net> writes:
> On Thursday 02 September 2010 03:52:23 Russ Allbery wrote:
>> As soon as you introduce a configuration management system, for
>> example, a lot of that automation is no longer useful, since it manages
>> configuration files you're now managing another way.
> I don't think I follow you here... for all I know modern configuration
> management is basically about automation in saying, that it allows for
> configuration management by means of definition/declaration/enforcing so
> they are basically the same thing. And, of course, with regards of SCM
> all that basically changes is that you track your definition tools
> instead of the configuration files which are now a product of the
> configuration management system instead of a direct source.
Well, to some extent it's a problem with how the user-friendly automation
of integration is done. But my experience is that most of the
user-friendly setup and automation looks quite a bit like a (limited,
special-purpose, non-scalable) configuration management system. So if
you're using a configuration management system, it's not helpful.
If one looks at how Microsoft handles, say, Active Directory setup, one
finds that the reason why it's so user-friendly and automated is because
it essentially embeds a configuration management system. This is typical,
in my experience, in the Microsoft space: Microsoft has an end-to-end
integrated solution, and as long as you stay within that solution and use
the modification points they built in, it all works together quite well.
But that includes using its notion of configuration management.
If I had something equivalent for, say, Kerberos and LDAP setup and
configuration, I wouldn't be able to use it since it would immediately
clash with Puppet. It would want to deploy configuration files that need
to be managed in Puppet, make configuration changes during setup that I
want to control with Puppet, and so forth. Sometimes when there's no
choice but to use that sort of setup, I'll run it and then try to find all
the configuration files it wrote out so that I can import them all into a
real configuration management system. But I'd much rather have simple
text configuration files with good documentation so that I can write my
own initial configuration to import into Puppet.
What Microsoft does is essentially assume their version of Puppet so that
they can write data directly into it. They make a lot of simplifying
assumptions based on the idea that they know what your technology choice
is for each separate component of a large system (namely, the one from
Microsoft), which we can't make.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: