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

Ansible 2.1 Released, with Network Automation, Containers

redhat.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Ansible 2.1 Released, with Network Automation, Containers

#81

Post by bpchaps »

ymse wrote: post #80
bpchaps wrote: post #76

Earlier quoted context omitted.

It's gotten so bad with these sorts of tools with their incredibly annoying design flaws that I've been debating creating my own using rpm and ssh on top of bash with some python. I get why it's important to have a lot of the features, but when the devops crowd thinks [0] is acceptable (or at the very least, doesn't scream about it), then it might be time for something new.. with [1] in mind. [0] $ man salt 2>/dev/nu…

Which design flaws are you referring to? As a recent Salt convert (and Puppet expert), I was perplexed as to why such a nice tool would have a man page 40x longer than bash . Turns out it includes extensive documentation for all states supported by Salt, generated from the online documentation. Compare this to the Puppet manual: $ man puppet PUPPET(8) Puppet manual PUPPET(8) NAME puppet See ´puppet help´ for help on…

"Design flaw" might not be right description. Maybe, "Naive implementations with nearly useless documentation" is better.

When I first started using puppet, I would go home absolutely exhausted every night. Their design choices, along with a lack of documentation, would turn the equivalent of a 20 minute bash script into something that would take days. Best example I can think of is the arbitrary ordering of module execution. I understand why they do it this way, but if they documented it in plain sight, then maybe my desk wouldn't have a forehead shaped dent in it. Similar goes for the other tools.

The only thing I can think of that prevents companies from releasing proper documentation is because of their expensive support contracts. There's a lot of incentive to make a standard incredibly difficult.

I just want accessible tools :(

edit: fss looks pretty neat! Kinda rpm-y, but it fits a nice middle ground.

Re: Ansible 2.1 Released, with Network Automation, Containers

#82

Post by andmarios »

JTenerife wrote: post #61

I love and hate Ansible. It has simplified so many things for me, but also had some annoying bugs and regressions. Somehow I've lost trust in the codebase. Also performance is a showstopper. I need a tool to develop, I just can't wait > 10 min for an iteration. I usually end up modifying my server's config files manually and then build the Ansible templates. Unfortunately I'm not aware of a better alternative.

Use tags and only play the role you fixed.

Re: Ansible 2.1 Released, with Network Automation, Containers

#83

Post by ymse »

bpchaps wrote: post #81
ymse wrote: post #80

Earlier quoted context omitted.

Which design flaws are you referring to? As a recent Salt convert (and Puppet expert), I was perplexed as to why such a nice tool would have a man page 40x longer than bash . Turns out it includes extensive documentation for all states supported by Salt, generated from the online documentation. Compare this to the Puppet manual: $ man puppet PUPPET(8) Puppet manual PUPPET(8) NAME puppet See ´puppet help´ for help on…

"Design flaw" might not be right description. Maybe, "Naive implementations with nearly useless documentation" is better. When I first started using puppet, I would go home absolutely exhausted every night. Their design choices, along with a lack of documentation, would turn the equivalent of a 20 minute bash script into something that would take days. Best example I can think of is the arbitrary ordering of module e…

I get your sentiment. I only started using Salt some months ago, but it was really a breath of fresh air compared to Puppet. However it took me a while to realize its true strengths since the documentation is very...dry.

IIRC Ansible, like Chef, does serial execution. That is, states are applied in the order they are written. I think that's part of the reason it has gotten so popular, as you'll have very few surprises in the vein of "what do you mean there is no ntp_service -- it's right there next to the config declaration!".

What Salt got right is the pillar, for which the Puppet equivalent (Hiera) was an afterthought. The Salt engine allows you to generate states from the pillar, rather than making poor clones of Puppet modules (as most of the formulas I've seen online).

However that flexibility is not documented anywhere, nor part of best practices. Nevertheless I'm about to release a set of formulas that are truly pillar-driven with no hard-coded stuff. Keep an eye out for the accompanying blog post :)

Of course, if you don't care about data/code separation and just want to get stuff done, there are better tools. And if you have full control of your environment, I would strongly suggest using Guix and/or Nix rather than these legacy configuration management tools.

Re: Ansible 2.1 Released, with Network Automation, Containers

#84

Post by bpchaps »

ymse wrote: post #83
bpchaps wrote: post #81

Earlier quoted context omitted.

"Design flaw" might not be right description. Maybe, "Naive implementations with nearly useless documentation" is better. When I first started using puppet, I would go home absolutely exhausted every night. Their design choices, along with a lack of documentation, would turn the equivalent of a 20 minute bash script into something that would take days. Best example I can think of is the arbitrary ordering of module e…

I get your sentiment. I only started using Salt some months ago, but it was really a breath of fresh air compared to Puppet. However it took me a while to realize its true strengths since the documentation is very...dry. IIRC Ansible, like Chef, does serial execution. That is, states are applied in the order they are written. I think that's part of the reason it has gotten so popular, as you'll have very few surprise…

I actually really like salt, just not its documentation. Like you said - it was a breath of fresh air. :)

Last time I used it a few months ago, it was while helping out another admin. He had a lot of confusion on how to do certain things, and the documentation wasn't very helpful for either of us. The solution came from github, which has become my go-to for these sorts of tools. Though, that could easily be supplemented with some better examples on their site, or in their, erm, man page.

I doubt we'll have some great tools with great documentation anytime soon (or monitoring tools!), but a sysadmin can dream... :)

Re: Ansible 2.1 Released, with Network Automation, Containers

#85

Post by bovermyer »

JTenerife wrote: post #58
bovermyer wrote: post #21

Earlier quoted context omitted.

This isn't quite accurate. It won't uninstall or remove things that a previous version put into place, unless you explicitly remove them before installing them as part of your playbooks/roles.

Exactly. This whole "declare your environment" thing with Ansible doesn't work. I've completely mixed experiences with Ansible. Yes, it's easy to get started, but it's certainly annoying having to create playbooks for removing stuff to get a clean state.

To be frank, my experience with configuration management has been a mix between "YES! THIS IS WHAT WE NEED!" and "...but it still doesn't adhere to immutable states." That's been true with Chef, Puppet, and Ansible, for me. I haven't experimented with other techs.

Re: Ansible 2.1 Released, with Network Automation, Containers

#88

Post by collyw »

threatofrain wrote: post #50
gerbilly wrote: post #48

Earlier quoted context omitted.

>any mature syntax tree parsers should be able to do it. Well thats' just it, I don't think they use such a parser. I always thought that's why they use YAML as their input language, to avoid having to write a parser, I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design. [1] https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 (Also k…

I speculate that Ansible choose YAML under the premise that it would lower the barrier to entry as opposed to a real language like Python or whatever. That would be nice if everything were just a matter of configurations, in which case YAML would be just as good as JSON, if not better. The problem is that because people want logic, Ansible ended up introducing an idiosyncratic YAML-templating language that's not actu…

JSON is crap for configuration. Its picky with quotes, doesn't like trailing commas, and isn't as readable as other options.

Re: Ansible 2.1 Released, with Network Automation, Containers

#89

Post by renaudg »

JTenerife wrote: post #61

I love and hate Ansible. It has simplified so many things for me, but also had some annoying bugs and regressions. Somehow I've lost trust in the codebase. Also performance is a showstopper. I need a tool to develop, I just can't wait > 10 min for an iteration. I usually end up modifying my server's config files manually and then build the Ansible templates. Unfortunately I'm not aware of a better alternative.

--tags and --start-at are your friends.

Re: Ansible 2.1 Released, with Network Automation, Containers

#90

Post by threatofrain »

collyw wrote: post #88
threatofrain wrote: post #50

Earlier quoted context omitted.

I speculate that Ansible choose YAML under the premise that it would lower the barrier to entry as opposed to a real language like Python or whatever. That would be nice if everything were just a matter of configurations, in which case YAML would be just as good as JSON, if not better. The problem is that because people want logic, Ansible ended up introducing an idiosyncratic YAML-templating language that's not actu…

JSON is crap for configuration. Its picky with quotes, doesn't like trailing commas, and isn't as readable as other options.

JSON is the example, not the prescription; JSON is just a widely used format for arbitrarily nested data. You can use Javascript objects (or Python dictionaries) if you want. Again, this example applies for the scenario if Ansible playbooks were only configurations. If it were only configurations, then fine, let's go with readable YAML.

If Ansible were playbooks with only configurations, then even XML would be okay, because in the sum of all pros and cons, this would be a tiny factor. The pickiness of quotes and trailing commas is really whatever here.

But instead Ansible playbooks use a "readable" YAML-ish language. The price is not right.

Post reply on HN