>>>>> "Phillip" == Phillip Steinbachs <p...@steinbachs.org> writes:
Phillip> On Thu, 25 Apr 2013, Atom Powers wrote: >> Because configuration management is about a lot more than "running ssh in a >> 'for' loop." >> >> I've been using CfEngine for about a decade and recently moved to a puppet >> infrastructure. I can say with confidence that there are times when you >> want to have more control over what your configuration management system >> does than to run a sequence of commands on a set of hosts. If all you use >> it for is to boot-strap a system then a series of commands (properly >> customized for environment, operating system, role, etc.) is sufficient. >> >> If you want to *manage* the configuration of the system after it has been >> deployed then you need additional logic to, for example, avoid installing >> the same package every half hour, detect if something on the system has >> changed and take a specific action, update a package to a specific version >> only on hosts running a specific version of an operating system, etc. >> >> Sure, you can do anything with a command, and puppet has it's own >> limitations, but ask yourself /why/ you are implementing configuration >> management and choose the right solution for your environment. >> Phillip> Maybe I'm misunderstanding, but you seem to be implying that Phillip> Salt is not helping you do anything more than run commands. Phillip> If so, it's important to note that it can both run commands Phillip> and manage config ala puppet style. I would actually call Phillip> this a major advantage, because it allows people who have no Phillip> configuration management in place to start using a real Phillip> configuration managment tool and be productive right now, and Phillip> then gradually work their way into more advanced ways of Phillip> doing things. This has been the big issue keeping me from deploying configuration management at $WORK, because I have to convince all the rest of the team that it's really worth the hassle and change in mind set. For me, supporting Solaris 8/10 Sparc/x86_64 systems and a bunch of RHEL 3/4/5 (mostly 5 now) x86_64 compute nodes, the attraction of cfengine has always been that it's self contained. I can just drop the cfengine binaries in place and away I go. Chef, puppet, etc all seemed to want me to first install python or ruby or something else that wasn't part of my base systems. This has changed over time, and esp as I've finally moved away from Solaris 8 in a big way. So looking at Salt and seeing that it requires Python is still a gotcha, but possibly one I can deal with now. But again, it's all about getting a system in place which I can encourage the rest of my team to use without causing them undue pain. Yes, sometimes you need to force the change, but it would be better if I didn't have to. This would be a good discussion to have, and one I keep wanting to have. John _______________________________________________ Discuss mailing list Discuss@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
