No, there's no reason to limit it, nor any reason to assume the status quo must hold.
There's nothing saying koan can't gain more support for more idempotent configuration runs and couldn't be put on a crontab. This is probably an area where it will only grow. Most of the complexity in configuration management tools is not needed when the packages do most of the work. What's left is mostly around blasting out templates, and if you need a more complex system, it can integrate with those. Is Cobbler just a provisioning app when it also does repo mirroring and updates, and can reboot your machines for you? Not really. I actually like what's been added to Cobbler to support better files/package integration a good amount. Incredibly lightweight, super simple, and doesn't require you to learn a programming language. Plus I really like that you can use the same templates for kickstart that you use post-kickstart. Now imagine using Func or another tool to trigger koan runs, and you have a full system. (But we'll leave choosing that up to you, crontab would be fine). Writing a configuration management system into Cobbler (well, Func) was always something I wanted to do, it was always not organizationally compatible. To be clear, I have no interest in competing with full-on management stacks -- there's nothing to win -- but for people who still want to manage their systems simply without learning a modeling language I think we can do that very very well. And, in accordance with Cobbler philosophy, we'll not force you to go either way. Configuration is largely about files. We help you manage those things at runtime. Nothing wrong with using the word. Many folks who are pushing out hosted apps with different deployment models (even Capistrano, etc), just don't need something that heavy. --Michael On Thursday, December 22, 2011 at 11:57 AM, David Lee wrote: > Michael DeHaan wrote: > > Thanks, totally agree. > > [...] > > > > > Thanks. Glad to that, as a newbie to cobbler, I'm getting this > more-or-less right. > > > [...] > > Then there are a few things that probably don't have pages on them, > > where we could take them off the main page too. > > > > * power management > > * PXE (boot loop prevention, menu generation, etc) > > * configuration management (section exists already about puppet, but > > should merge in the built-in config stuff and make easier to understand) > > [...] > > > > > I've always been uneasy about the way cobbler talks about "configuration > management". > > Installed machines can have a life-cycle of several years. It is in > this long-term, ongoing maintenance context that products such as > cfengine and puppet use the term "configuration management". > > But when cobbler documentation uses this same term, it isn't talking > about long-term maintenance at all. Rather it is talking about > "configuration initialisation": getting some sort of initial > configuration onto the machine that will probably do for the moment, > where "for the moment" means "while my mind is on the business of > getting this machine started; probably less than a day; probably less > than an hour; probably less than even 15 minutes". > > > So I would suggest that we give care to our use of terminology and > intention. I suggest we reserve the term "configuration management" for > its generally understood long-term maintenance purpose (cfengine, > puppet, etc.), and introduce a term such as "configuration > initialisation" to discuss our activities of doing the initial > tailoring. This initial tailoring might include hooks to install > cfengine/puppet and just enough to get them started; it might include > the material (hitherto called "config management", such as "management > classes" etc.). > > > > -- David Lee > _______________________________________________ > cobbler mailing list > [email protected] (mailto:[email protected]) > https://fedorahosted.org/mailman/listinfo/cobbler > >
_______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
