Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Puppet: SaltStack or Ansible?

ryandlane.com

Post reply on HN
Print view View original

41–50 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#41

Post by bithive123 »

dgallagher wrote: post #12

Does anyone have experience using Configuration Management software in a heterogeneous environment? For example, I've seen large environments running Windows 2008/2008R2/2012/2012R2, various flavors and versions of Linux including Ubuntu Server, CentOS, SUSE, etc... What's the pretty? What's the ugly? I understand consolidation and standardization of operating systems is usually the best state to be in, but in a lot…

In theory Puppet would be good for the Linux servers at least because it lets you declare things in an abstract way that can hinge on variables like distro, release, etc.

In practice the Puppet language is only tolerable to the extent that it provides (or helps you create) abstractions for everything, and now you have two problems as they say.

Re: Moving away from Puppet: SaltStack or Ansible?

#42

Post by ryan_lane »

mpdehaan2 wrote: post #39
ryan_lane wrote: post #35

Earlier quoted context omitted.

In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. After I pointed out why this was in fact a valid bug, the bug wasn't reopened, but instead left closed while I was told "you're welcome to submit a PR". Basically I'm being told the bug isn't important enough for the upstream to fix and that they care so little about the bug that they won't even leave it open for someone othe…

Hi Ryan, I'm sorry you feel that way. In our case, we get a TON of bug report traffic - many are just user questions which we'll direct to the list, some are just nice to haves, we file most of the good ones, but not always. Though I would consider performance tuning of the user module not a bug, and I do not think the newline behavior of copying the file on the filesystem was a bug either. A discussion on ansible-pr…

Yep. I understand that, but part of having an open source project is that others may find open bugs and decide to fix them because they're also having the same issue. Closing legitimate bugs hides them from the world and also gives people the impression that it's not something to fix.

The performance issue was very likely one of the more major deciding factors. Managing users was so slow that it was painful to do small iterative development. Slow performance is definitely a bug.

Re: Moving away from Puppet: SaltStack or Ansible?

#43

Post by mpdehaan2 »

ryan_lane wrote: post #42
mpdehaan2 wrote: post #39

Earlier quoted context omitted.

Hi Ryan, I'm sorry you feel that way. In our case, we get a TON of bug report traffic - many are just user questions which we'll direct to the list, some are just nice to haves, we file most of the good ones, but not always. Though I would consider performance tuning of the user module not a bug, and I do not think the newline behavior of copying the file on the filesystem was a bug either. A discussion on ansible-pr…

Yep. I understand that, but part of having an open source project is that others may find open bugs and decide to fix them because they're also having the same issue. Closing legitimate bugs hides them from the world and also gives people the impression that it's not something to fix. The performance issue was very likely one of the more major deciding factors. Managing users was so slow that it was painful to do sma…

I think it's something that can be improved, yes. I'm not sure it's a bug, and I'm not sure it's really all that slow. We're talking about 0.5 seconds and maybe it could get down to 0.4? If you dig into the module I'm not sure what you would change. (Again, a fine discussion for ansible-devel probably? How would you solve it?)

In your case, managing a list of 80 users to be sure there or not, I might have suggested perhaps tagging that action and only running that every so often, but I do think that, in general, it wasn't a pressing thing for us.

There are going to be occasional tradeoffs to the way the task system does work (ability to be split declarative/imperative), but those are some of the prices to be had for the flexibility that can by (like "register:" versus the limitations of a server side compile up front).

I think I'm ok with that, all being said. It's how ansible came to be.

There are choices that you take building things one way versus another, and if we're down for time for a coffee and three spins around the office chair, or time for coffe and two spins around the office chair, it's still in statistical noise territory.

We have spent a lot of time optimizing the HECK out of the SSH transport, but no matter what, almost all deployments in any config tool, the majority of the time comes down to waiting on yum and apt. And yum and apt are brilliant and I love them, it's just where things lurk :)

Re: Moving away from Puppet: SaltStack or Ansible?

#44

Post by ryan_lane »

mpdehaan2 wrote: post #40
ryan_lane wrote: post #37

Earlier quoted context omitted.

I'll follow-up with a post about how we're working without a master. We need neither SSH, nor a master. We're very heavily using autoscaling, which makes SSH a no-go. Ansible has Tower for this, but it's proprietary. We /could/ use a salt master for autoscaling, but we prefer masterless in this situation because it scales better.

ansible-pull is available for those that need to invert the architecture, though we're finding most users in companies who need autoscaling can afford Tower. Price points are definitely important in that regard, but ansible-pull does exist for those that would rather go the pure OSS route. Tower is also free for up to 10 nodes. See my comments above about why we went that route - being able to build products versus h…

Open core also has its set of issues. For most open core products I've used over time the community starts creating alternatives to the proprietary products and the upstream slows its acceptance of open code. The upstream will also tend to spend most of its time working on proprietary features.

Whether or not tower costs money, it's still a worry of being a single point of failure for autoscaling, which is part of why we avoided masters.

Re: Moving away from Puppet: SaltStack or Ansible?

#46

Post by geerlingguy »

willthames wrote: post #17
mpdehaan2 wrote: post #5

Hi ansible author here! This was definitely an interesting comparison but to correct a few misconceptions: Ansible has 810 contributors at this point. I'd love to say I wrote everything but it's a huge shared effort. We also have a lot of mods other projects don't, so some comparison aspects were not even. We do say no when we disagree. I think that's important. Filtering and testing makes a project what it is to a d…

This seems illuminating. "The only complaint that I have here [about Salt] is that they are sometimes less rigorous than they should be when it comes to accepting code (I’d like to see more code review)." Keeping high quality across a project requires discipline. And that discipline can sometimes seem cold. "pull request welcome" is at the warm end of the spectrum.

And in my experience, submitting a well-reasoned, simple pull request to add a small change or fix a bug always results in a merge.

As someone who also maintains a few (much, much smaller) OSS projects on GitHub, I really understand the 'no' mentality. It's often much harder to say no, but usually I try to put it in a positive way (yes, this is a worthwhile idea, yes, it looks like it could help in this situation, but no, I won't be merging it because I don't think most of the project's users would benefit from its inclusion).

Re: Moving away from Puppet: SaltStack or Ansible?

#47

Post by mpdehaan2 »

geerlingguy wrote: post #46
willthames wrote: post #17

Earlier quoted context omitted.

This seems illuminating. "The only complaint that I have here [about Salt] is that they are sometimes less rigorous than they should be when it comes to accepting code (I’d like to see more code review)." Keeping high quality across a project requires discipline. And that discipline can sometimes seem cold. "pull request welcome" is at the warm end of the spectrum.

And in my experience, submitting a well-reasoned, simple pull request to add a small change or fix a bug always results in a merge. As someone who also maintains a few (much, much smaller) OSS projects on GitHub, I really understand the 'no' mentality. It's often much harder to say no, but usually I try to put it in a positive way (yes, this is a worthwhile idea, yes, it looks like it could help in this situation, bu…

Yep, we definitely try to.

Part of the difficulty comes from the dynamic changes of GitHub. 10 years ago, usually folks would discuss a change prior to submitting code.

Now, it's more common for someone to assume code is wanted, and then it's easy to be a little disappointed when you find an upstream would want it implement differently.

In all though, GitHub has done wonders for standardizing contribution processes.

Re: Moving away from Puppet: SaltStack or Ansible?

#48

Post by magnacartic »

eff wrote: post #4

I've been using SaltStack + SaltCloud in a production environment for the past six months or so -- it's been a total joy compared to my experiences with Puppet / Chef.

Indeed! I've been using Salt in production since January and I haven't missed Puppet/Chef too, even though the initial learning curve was steep.

Re: Moving away from Puppet: SaltStack or Ansible?

#49

Post by mpdehaan2 »

rdtsc wrote: post #45

I usually look at Salt as more advanced and perhaps a replacement of Puppet and other such declarative configuration system. I see Ansible as more of a replacement of a bunch of SSH + scripts.

Basically with Ansible all the declarative stuff in ansible is there and you'll be able to do all those things you want to do from Puppet and Chef.

However you can also do the app deployment stuff that you would typically do with Fabric or Capistrano.

The point really is to avoid using both, but in many ways, you could start with one, or only use one.

There are definitely folks in various stages of development where they start with one side of the coin and eventually migrate both sides.

But yeah, app deployment is definitely a focus, and I think for most people is a bigger driver than the basic config management stuff.

But is the declarative stuff there? 100%.

Re: Moving away from Puppet: SaltStack or Ansible?

#50

Post by mpdehaan2 »

ryan_lane wrote: post #44
mpdehaan2 wrote: post #40

Earlier quoted context omitted.

ansible-pull is available for those that need to invert the architecture, though we're finding most users in companies who need autoscaling can afford Tower. Price points are definitely important in that regard, but ansible-pull does exist for those that would rather go the pure OSS route. Tower is also free for up to 10 nodes. See my comments above about why we went that route - being able to build products versus h…

Open core also has its set of issues. For most open core products I've used over time the community starts creating alternatives to the proprietary products and the upstream slows its acceptance of open code. The upstream will also tend to spend most of its time working on proprietary features. Whether or not tower costs money, it's still a worry of being a single point of failure for autoscaling, which is part of wh…

We've never held back anything from Ansible, really. Rather, Tower is more of a product on top that provides some extra enterprise features that most of our user bases don't need (but they should try it, because they might!).

I think if you see things like Windows being part of Ansible proper, it's clear we're not holding that back. But there are also tools the OSS community can't build easily, things that involve coordination around database schemas and (ick!) status meetings and UX mockups.

Yes, communities can build them, but occasionally, just occasionally, companies can build them better. And this is one of those cases. Our business model basically funds Ansible and also makes Tower significantly more capable that way, and it only becomes something you need when you can afford it. And it's not so much because we're a company, because I've got tons of awesome folks working in 100% full time, and that's a lot of power to build good stuff. Most likely your company employs a few folks as well :)

So on the "open core" comment, Ansible won't, for instance, ever have proprietary modules. That's something we said we don't do. Ever.

As for Tower, the small guy isn't going to need it yet. He's probably ok with pure Jenkins fronting the show. The big guy probably needs it and a super-well-tested environment and a guy to call when it has issues.

I don't know anything about other communities you've been a part of, but I think our track record shows what goes where and people are comfortable with it. Ansible isn't open core. It's the real deal. We take that seriously.

Yet, I think the general assumption that all software has to be purely 100% open is flawed, but that in general, open source communities can build some things in GREAT fantastic ways, and certain layers do benefit from being free software. But companies need to exist. Including yours! (Though I do love me some Uber).

Anyway, ansible-pull is indeed an option if you wanted to go that wrote, or even doing image builds with Packer. Both popular options for immutable systems and/or autoscaling, sans commercial bits.

But is commercial software dirty? Heck no. Ask any SaaS company :)

Post reply on HN