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

91–94 of 94 posts

Re: Ansible 2.1 Released, with Network Automation, Containers

#91

Post by shlant »

willejs wrote: post #70
shlant wrote: post #67

Earlier quoted context omitted.

Definitely agree with this. I use the docker module extensively and found 2 regressions[1][2] that I went through the trouble of debugging down to a single commit, but still have no idea whether anyone is going to fix them. I'm hoping now that they are done rewriting the docker modules, and considering they are using docker as a selling point for 2.1, they will be more proactive with these issues. 1. https://github.c…

Look at Chef. Its extensively unit tested in both the core client & server, but also the cookbooks associated with it. Check out the docker one for example https://github.com/chef-cookbooks/docker The interfaces and primitives for docker in this cookbook are great too.

I used to be a Chef user, and although I do love it, it's overkill for the current infra I am supporting. I haven't had too many issues with Ansible, I love it's simplicity, just lately there have been some annoying regressions.

I do really appreciate that testing is a priority in the Chef community, cause it definitely isn't with Ansible. It also seems like based on the naming conventions in the Chef cookbook, that Ansible is playing catchup with 2.1 (imitation is the sincerest form of flattery?)

Re: Ansible 2.1 Released, with Network Automation, Containers

#92

Post by jmcnulty »

earless1 wrote: post #40
movedx wrote: post #14

Earlier quoted context omitted.

Your systems is already down, rolling back is the same thing, if not more effort than rolling forward. At least that's what I've always found. Another option is to have customers point at stage after it has been upgraded and if it all goes horribly wrong, a load balancer change should be enough to point people back at the older production environment. All this being said, problems in production shouldn't be a thing w…

Keeping a system down while waiting for a hotfix is not an option for most operations. Rollbacks have their place and hotfixes have their place.

Taking a snapshot of a system before making a change and rolling back to that snapshot would be faster. In any case, a strong policy of only pushing changes to production that have been properly tested in staging will protect you the most.

Re: Ansible 2.1 Released, with Network Automation, Containers

#93

Post by jmcnulty »

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.

Depends how you write your playbooks/roles. You can write a role that will both add and remove depending on the value of a variable in your inventory. Then tweak the inventory and re-run.
Post reply on HN