4 ms·

This is a weird "open letter" but okay. I feel like Puppet, for whatever reason, has lost out on things and Ansible won, which is quite unfortunate as Ansible

by lapser 4y ago

This is a weird "open letter" but okay. I feel like Puppet, for whatever reason, has lost out on things and Ansible won, which is quite unfortunate as Ansible is just not as good as Puppet. I wonder if Preforce will be able to revive the interest in Puppet. Anyway, if someone plans to move away from Puppet (I imagine someone will, because someone always disagrees with a buyout), I've recently found mgmt[0] which has Puppet-lang compatibility. A big plus (to me anyway) is that it's not Ruby based, and is instead written in Go. [0] https://github.com/purpleidea/mgmt https://github.com/purpleidea/mgmt

zukzuk 4y ago
Why would it not being Ruby-based be a plus? Go is a big improvement over Ruby in some use cases, like where performance or concurrency is important, but this is not one of those cases.
- lapser 4y ago
  Personal opinion, I'm sure many will disagree, but I've never been a fan of Ruby. It tends to be slow and, at least last time I used Puppet, there was a lot of dependency issues (from downloading them, to ensuring you run the right version of Ruby among other things). Whereas with Go downloading a single binary takes a whole lot of headaches away. Sure concurrency/performance won't matter much in the case of Puppet like software but depending on a single binary vs lots of dependency is a huge bonus.
  - brightball 4y ago
    Rails is often slow. Ruby's plenty fast though. Puppet was trying to do a lot with the way that it was designed and I think it's probably a side effect. Ansible can be plenty slow at time too.
    - lapser 4y ago
      > Ansible can be plenty slow at time too. Yep, I've never been a fan of Ansible. Beyond that slowness of it, the fact that it's duct tape of YAML and shell with randomness and a sprinkle of YAML craziness make it really hard for me to like it.
      - brightball 4y ago
        Fwiw, despite all that I still prefer it to the alternatives because it doesn't require an agent and is easy to use anywhere you have SSH access. So whether it's officially part of the agreed upon tools or not, I can still use it to make my own life easier vs raw SSH.
    - lamontcg 4y ago
      Rubygems is slow, the way that it requires files from libraries is by scanning through every gem, for every file, every time. Which is particularly brutal on Windows. It probably doesn't need to be that way via either extending the syntax to require from a specific gem and/or to have a file manifest database (and lose some manual hack-it-up-itude)
sc68cal 4y ago
Ansible won out because Puppet had scaling issues. OpenStack infra at one point was using Ansible to orchestrate puppet pulls, until everything could be re-written in Ansible
- dapak 4y ago
  I'm genuinely interested in what the infrastructure was that couldn't support orchestration of Puppet clients. I hear this from people sometimes and it usually ends up being related to poorly architected Puppet infrastructure for their environment. A properly architected Puppet environment should have no problems dealing with thousands of clients.
  - nprateem 4y ago
    The non-deterministic run order was a nightmare to debug so everyone moved to ansible
    - apple4ever 4y ago
      That's exactly it. Trying to fight to get things to run in a proper order was a nightmare.
  - jmcnulty 4y ago
    Depends what you want to do. If you're happy for changes to dribble in over time then size your puppetmaster pool to how many hosts you want to be able to run puppet simultaneously and stagger client execution to avoid a stampeding herd. Accept that sometimes there will be individual failures due to load and clients will just have to wait till the next time. Alternatively, in real life, many teams have Change Management to consider and Maintenance windows. If there's a need to update thousands of systems on a saturday morning then expect teams to start puppet runs manually. You'd better have a seriously big pool of puppetmasters ready and waiting to manage the load, and don't forget Puppet DB, that has to be scaled up too to avoid lock ups. Even then, if teams start too many puppet runs at once, you'll get flattened. We ended up scrapping all the puppetmasters in individual DCs and consolidating them in an AWS EC2 Autoscaling group. The number of puppetmasters started at 70 and just went up. That came with problems of its own. e.g. ensuring that all puppetmasters share the same copy of role versions at the same time. Being able to spin up new puppetmasters fast enough to meet spikes in demand. Various other corner case tuning issues. It's taken a dedicated team years to get to grips with puppet, tame it and master it. Very glad I'm not involved in that any more.

by lapser 4y ago

zukzuk 4y ago

Why would it not being Ruby-based be a plus? Go is a big improvement over Ruby in some use cases, like where performance or concurrency is important, but this is not one of those cases.

lapser 4y ago
Personal opinion, I'm sure many will disagree, but I've never been a fan of Ruby. It tends to be slow and, at least last time I used Puppet, there was a lot of dependency issues (from downloading them, to ensuring you run the right version of Ruby among other things). Whereas with Go downloading a single binary takes a whole lot of headaches away. Sure concurrency/performance won't matter much in the case of Puppet like software but depending on a single binary vs lots of dependency is a huge bonus.
- brightball 4y ago
  Rails is often slow. Ruby's plenty fast though. Puppet was trying to do a lot with the way that it was designed and I think it's probably a side effect. Ansible can be plenty slow at time too.
  - lapser 4y ago
    > Ansible can be plenty slow at time too. Yep, I've never been a fan of Ansible. Beyond that slowness of it, the fact that it's duct tape of YAML and shell with randomness and a sprinkle of YAML craziness make it really hard for me to like it.
    - brightball 4y ago
      Fwiw, despite all that I still prefer it to the alternatives because it doesn't require an agent and is easy to use anywhere you have SSH access. So whether it's officially part of the agreed upon tools or not, I can still use it to make my own life easier vs raw SSH.
  - lamontcg 4y ago
    Rubygems is slow, the way that it requires files from libraries is by scanning through every gem, for every file, every time. Which is particularly brutal on Windows. It probably doesn't need to be that way via either extending the syntax to require from a specific gem and/or to have a file manifest database (and lose some manual hack-it-up-itude)

sc68cal 4y ago

Ansible won out because Puppet had scaling issues. OpenStack infra at one point was using Ansible to orchestrate puppet pulls, until everything could be re-written in Ansible

dapak 4y ago
I'm genuinely interested in what the infrastructure was that couldn't support orchestration of Puppet clients. I hear this from people sometimes and it usually ends up being related to poorly architected Puppet infrastructure for their environment. A properly architected Puppet environment should have no problems dealing with thousands of clients.
- nprateem 4y ago
  The non-deterministic run order was a nightmare to debug so everyone moved to ansible
  - apple4ever 4y ago
    That's exactly it. Trying to fight to get things to run in a proper order was a nightmare.
- jmcnulty 4y ago
  Depends what you want to do. If you're happy for changes to dribble in over time then size your puppetmaster pool to how many hosts you want to be able to run puppet simultaneously and stagger client execution to avoid a stampeding herd. Accept that sometimes there will be individual failures due to load and clients will just have to wait till the next time. Alternatively, in real life, many teams have Change Management to consider and Maintenance windows. If there's a need to update thousands of systems on a saturday morning then expect teams to start puppet runs manually. You'd better have a seriously big pool of puppetmasters ready and waiting to manage the load, and don't forget Puppet DB, that has to be scaled up too to avoid lock ups. Even then, if teams start too many puppet runs at once, you'll get flattened. We ended up scrapping all the puppetmasters in individual DCs and consolidating them in an AWS EC2 Autoscaling group. The number of puppetmasters started at 70 and just went up. That came with problems of its own. e.g. ensuring that all puppetmasters share the same copy of role versions at the same time. Being able to spin up new puppetmasters fast enough to meet spikes in demand. Various other corner case tuning issues. It's taken a dedicated team years to get to grips with puppet, tame it and master it. Very glad I'm not involved in that any more.