Can someone explain why this is an anti-pattern? Is there some sarcasm I'm missing? Seems like exactly the kind of response I appreciate when I submit issues in open source projects.
Moving away from Puppet: SaltStack or Ansible?
11–20 of 182 posts
Re: Moving away from Puppet: SaltStack or Ansible?
#12I understand consolidation and standardization of operating systems is usually the best state to be in, but in a lot of larger companies running legacy software it's not economically feasible to do.
Re: Moving away from Puppet: SaltStack or Ansible?
#13> I did get a “pull request welcome” response on a legitimate bug, which is an anti-pattern in the open source world. Can someone explain why this is an anti-pattern? Is there some sarcasm I'm missing? Seems like exactly the kind of response I appreciate when I submit issues in open source projects.
Some people believe that maintainers should fix all bugs that are reported to them. Other people believe that the open-source nature of the software should cause people to fix their own bugs and contribute the fixes back to the project, and both camps often believe that demands on their own time and effort are unreasonable.
Re: Moving away from Puppet: SaltStack or Ansible?
#14Personally a fan of Ansible, but I've also been pretty impressed by SaltStack as well. Either is much simpler and easier to use than the older generations of configuration management tools (cfengine, Puppet, Chef.)
Re: Moving away from Puppet: SaltStack or Ansible?
#15- Ansible is slow even when it doesn't have anything to do. This is true. For example, we manage lists of former users that should not exist on systems, this gets quite slow. I think that the slowness is mostly due to SSH, but it could be smarter about bulk operations, I suppose.
- Custom DSL looping and conditionals. This was intended to make the system simpler and easier, but I agree with the author that I also have to revisit the documentation since looping in a template (jinja) is different than looping in a task (with_ directives).
- Task variable registration opacity. Yup, lots of debug: actions.
People in IRC are pretty friendly, but I did get a tone of "you're doing it wrong." This is exemplified, I think, by the author's "global ignore_errors" feature request. I made a suggestion that ansible-playbook should be able to run a role without having to create a stub playbook that calls the role. I ended up creating a bash script for it, but the response on IRC was in the vein of: I don't use it that way, you are doing it wrong. To me, Ansible is another tool in my sysadmin chest, I am going to use it in the way that works best for me. It's nice if the tool supports my workflow.
The remarks about the friendliness of the Salt community are enough to get me to take another look... Oh, and also that Salt released its webUI (Halite) to the community, but Ansible's AnsibleWorks is closed. A UI can go a long way towards increasing usage.
It's lightyears better than Puppet/Chef, and I am glad both exist. :)
Re: Moving away from Puppet: SaltStack or Ansible?
#16> I did get a “pull request welcome” response on a legitimate bug, which is an anti-pattern in the open source world. Can someone explain why this is an anti-pattern? Is there some sarcasm I'm missing? Seems like exactly the kind of response I appreciate when I submit issues in open source projects.
"Pull request welcome" usually means "This is a legitimate bug, but I don't care enough to fix this for you." Some people believe that maintainers should fix all bugs that are reported to them. Other people believe that the open-source nature of the software should cause people to fix their own bugs and contribute the fixes back to the project, and both camps often believe that demands on their own time and effort ar…
Re: Moving away from Puppet: SaltStack or Ansible?
#17Hi 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…
"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.
Re: Moving away from Puppet: SaltStack or Ansible?
#18While I have been a happy Ansible user for some time, the criticisims that the author pointed out that really resonated with me were: - Ansible is slow even when it doesn't have anything to do. This is true. For example, we manage lists of former users that should not exist on systems, this gets quite slow. I think that the slowness is mostly due to SSH, but it could be smarter about bulk operations, I suppose. - Cus…
The below is an example setup of a session that persists for ten minutes after last logout. Subsequent ssh attempts (or new parallel ssh attempts) will piggyback onto the session and avoid the renegotiation delay.
host *
ControlPersist 10m
ControlPath ~/.ssh/master-%r@%n:%p
ControlMaster autoRe: Moving away from Puppet: SaltStack or Ansible?
#19Does 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…
Traditional Windows folks don't really use configuration management or even have any clue about it. Or at least that's my impression. I'm a Linux guy and have been fighting a one-man battle to CM-ize our infrastructure. I have no interest in using Microsoft's DSC on the Windows side (their brand-new CM-like solution in PowerShell) and something else on the Linux side, and since I'm a Python developer I gravitated to Salt.
I love SaltStack (no real experience with Ansible). Although it supports Windows in a sense, it's very rough around the edges. Many modules will fail or have weird edge cases on Windows. I've gotten to the point where the only module I really trust to work 100% of the time is cmd.run (which executes arbitrary shell commands). That said, it's been a total win so far. I've almost completely replaced ad hoc Windows server provisioning with version controlled, documented Salt states. It's glorious.