3 ms·

I'm interested to know why someone would not recommend CM (or atleast not recommend puppet/chef). I think despite its faults, I've seen that many problems becom

by ashayh 15y ago

I'm interested to know why someone would not recommend CM (or atleast not recommend puppet/chef). I think despite its faults, I've seen that many problems become non-issues when you are using puppet. OTOH, I've seen organizations struggle for months(or for ever) with what could have been a simple solution with puppet. Could it be you made the wrong design decisions both times? Sometimes, people try to do complex things in puppet, when they should using puppet just to push out that cronjob or init script, or rpm/apt package to handle the complexity. Can you give more details like how many serves you have? Do you have a complex combination of hardware(physical + virtual) and operating system platforms? Do you have a complex combination of apps on these platforms? Did you use the "environments" feature of puppet/chef? (Environments are totally broken in puppet) Did you use Dashboard/Foreman or Grill(chef only) and did that make things easier? Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?

moe 15y ago
not recommend CM Sorry, that part was irony. I would of course recommend CM. I was just trying to express that the current crop of tools is nowhere near a level of maturity where you could recommend one or the other as a no-brainer. Could it be you made the wrong design decisions both times? Surely. More so with puppet than with chef as the puppet language offers slightly more rope to hang yourself on the foot. However, I'm quite confident we have maxed out both tools to about the best of their abilities now (short of the more esoteric extensions such as mcollective). There is of course always a next step, but I can't think of something that could potentially change my perception of their respective problem areas (which, as I outlined in my parent post, are pretty fundamental for each tool). Can you give more details like how many serves you have? Largest puppet deployment is ~70 hosts, largest chef is ~40 hosts. Yes, we've had to migrate the puppetmaster to a pretty beefy host. Yes, chef's claim to scalability is a joke. We experimented with couch replication but quickly went back to running separate (beefy) chef-servers and sync'ing them via git. A tangential reason for running separate puppetmaster/chef instances is the lack of a trustworthy security model in both. Extdata/databags do occasionally contain sensitive information, neither puppet nor chef accounts for that (don't get me started on "encrypted databags"). Do you have a complex combination of hardware(physical + virtual) and operating system platforms? We run (only) debian on physical and cloud servers. For cloud deployments chef works better for us. For physical servers we're rooted in puppet but slowly leaning towards chef for uniformity. I wouldn't say our deployments are especially complex. And even if they were then that'd be no excuse for the tools that were created to manage precisely that kind of complexity. Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef? The bigger clusters were built from scratch but we have chef/puppet clusters in various states of finesse. Oh, this reminds me of one of the less obvious issues that I forgot in my initial rant: Updates. You absolutely, positively want to either update your entire cluster (all puppet/chef clients) in lockstep with the server or not at all. The "backwards compatibility"-claims didn't work out for us when we tried.

by ashayh 15y ago

moe 15y ago

not recommend CM Sorry, that part was irony. I would of course recommend CM. I was just trying to express that the current crop of tools is nowhere near a level of maturity where you could recommend one or the other as a no-brainer. Could it be you made the wrong design decisions both times? Surely. More so with puppet than with chef as the puppet language offers slightly more rope to hang yourself on the foot. However, I'm quite confident we have maxed out both tools to about the best of their abilities now (short of the more esoteric extensions such as mcollective). There is of course always a next step, but I can't think of something that could potentially change my perception of their respective problem areas (which, as I outlined in my parent post, are pretty fundamental for each tool). Can you give more details like how many serves you have? Largest puppet deployment is ~70 hosts, largest chef is ~40 hosts. Yes, we've had to migrate the puppetmaster to a pretty beefy host. Yes, chef's claim to scalability is a joke. We experimented with couch replication but quickly went back to running separate (beefy) chef-servers and sync'ing them via git. A tangential reason for running separate puppetmaster/chef instances is the lack of a trustworthy security model in both. Extdata/databags do occasionally contain sensitive information, neither puppet nor chef accounts for that (don't get me started on "encrypted databags"). Do you have a complex combination of hardware(physical + virtual) and operating system platforms? We run (only) debian on physical and cloud servers. For cloud deployments chef works better for us. For physical servers we're rooted in puppet but slowly leaning towards chef for uniformity. I wouldn't say our deployments are especially complex. And even if they were then that'd be no excuse for the tools that were created to manage precisely that kind of complexity. Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef? The bigger clusters were built from scratch but we have chef/puppet clusters in various states of finesse. Oh, this reminds me of one of the less obvious issues that I forgot in my initial rant: Updates. You absolutely, positively want to either update your entire cluster (all puppet/chef clients) in lockstep with the server or not at all. The "backwards compatibility"-claims didn't work out for us when we tried.