|
|
|
|
|
|
by Goladus
5808 days ago
|
|
|
With those kinds of provisioning times, why would I want to bother with something that requires the extra step of "black art" bootstrapping[6]? At most extreme, to make a configuration change on a running system, I'd just need to trigger the installation of a new package version on the relevant systems. In my experience, "making a configuration change on a running system" is not an extreme case. It happens all the time, and 5-10 minutes of downtime for reboot just to add a comment to an apache configuration file is insanity. Especially if there's a problem and you need to rollback. Frankly, if you are booting machines in 5-10 minutes with all the packages they need, you've almost entirely solved the bootstrapping problem anyway. There are just a few security bits left. edit: I did a quick check of our subversion repository, it looks like our commits per month are in the 80-100 range. Systems get reconfigured, at least in minor ways, a LOT. Installing a new version of a package for every single change would be a huge amount of overhead. Far more than the one-time overhead of bootstrapping cfengine. In fact we could do it that way, if we wanted, but we don't. |
|
|
Agreed, since that comment doesn't warrant any deployment at all, but that's a strawman.
Especially if there's a problem and you need to rollback
This is, of course, a philosophical difference. How can one be sure that the rollback actually results in the previous state? For me, the certainty outweighs the speed increase.
Installing a new version of a package for every single change would be a huge amount of overhead
My reaction to this is that you must be doing something vastly different to install a package. Unless you're talking about an environment with just a handful of servers (in which case, why even bother with CM?), the overhead of building a package of text files would be less than that of checking them out from version control.