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

Ansible 4.0

groups.google.com

Post reply on HN
Print view View original

21–30 of 141 posts

Re: Ansible 4.0

#21

Post by AJAlabs »

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

With verison 4.0.0, they've implemented semantic versioning which should make life easier for avoiding breaking backwards compatibility changes.

https://semver.org

Re: Ansible 4.0

#22

Post by purpleidea »

encryptluks2 wrote: post #7

Pretty cool but Ansible just seems too slow to me. I'm just comparing this against like native scripting, Terraform, etc. I guess Ansible is still the best option for configuration management, but I keep hoping someone will come out with a new tool, preferably built with Go or Rust.

Um, you've seen https://github.com/purpleidea/mgmt/ right ;) Join us!

Re: Ansible 4.0

#23

Post by purpleidea »

blcknight wrote: post #11
encryptluks2 wrote: post #7

Pretty cool but Ansible just seems too slow to me. I'm just comparing this against like native scripting, Terraform, etc. I guess Ansible is still the best option for configuration management, but I keep hoping someone will come out with a new tool, preferably built with Go or Rust.

mgmt config is written in go and has a lot of interesting concepts.

Thanks for looking out for us =D Link for any who's interested: https://github.com/purpleidea/mgmt/ I and others have been working quite hard on it, so please come join us =D

Re: Ansible 4.0

#24

Post by kbenson »

oneplane wrote: post #6
pram wrote: post #5

Earlier quoted context omitted.

Final as in it's the actual release and not a candidate, not that it's the final version of Ansible jfyi

We have a word that describes that better than 'final': release. And if it's on physical media, you could even call it GM (Golden Master). They are not words that stand on their own, you would combine it with the artifact name and the version you are releasing. Release of the following: Name: ansible Version: 4.0.0 Combined, it's the "Ansible 4.0.0 Release" in whatever order makes sense. If you have something that is…

I think the reason "final" is used is because you'll often have releases like

Foo 2.0 alpha release

Foo 2.0 RC1

Foo 2.0 RC2

etc, and if you just have "Foo 2.0" as a release it can be somewhat ambiguous as to whether someone named something wrong when downloading or describing it and left of that portion of the name, or if it's actually the full release, so they want a word to distinguish it as the actual full and final release of that version and not "the 2.0 branch"

"Final" may not be the best word choice for that, but it does at least accomplish the task of distinguishing the actual final product of that version from any other types of releases or the branch that will eventually become that.

Re: Ansible 4.0

#25

Post by zhengyi13 »

aduitsis wrote: post #14

First of all, congratulations to the team of Ansible and these tools have benefited us in numerous ways that cannot be understated. Having said that, this caught my eye: > There may be backwards incompatibilities in the core playbook language. Please see the porting guide for details. Doing incompatible changes is not something specific to Ansible, for example Puppet has also done it time and again. We've been using…

I feel you: in our environment, we stayed on Puppet 3 for exactly the sort of reason you call out for the longest time, and upgrading our Puppet codebase to be 4+ compatible was a major effort.

OTOH, in the case of Ansible, I've had good success with `pip install --user` to get a local (to my user) Ansible install that's separate from the system, and it looks like specific versions of software can be requested.

Re: Ansible 4.0

#26

Post by dcolkitt »

zmmmmm wrote: post #12

I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. Is it in conflict with that because of its semi-imperative nature? Or is what it does an essential piece of how IaC needs to work to do declarative infrastructure management? I see that for example you can use ansible wi…

Even in container world, I still find Ansible/Chef useful for a number of low-level system tuning tasks. Things like setting NUMA affinities, modifying kernel parameters, setting IRQ interrupts, loading kernel modules, setting NIC parameters, etc. That kind of stuff is often overlooked, but done right can have pretty dramatic performance impact.

Re: Ansible 4.0

#27

Post by Alex3917 »

zmmmmm wrote: post #12

I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. Is it in conflict with that because of its semi-imperative nature? Or is what it does an essential piece of how IaC needs to work to do declarative infrastructure management? I see that for example you can use ansible wi…

> That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC.

As a developer working on a small startup, I don't like using Docker because it makes the fan on my MBP go crazy and drains the battery almost instantly. Whereas I've had zero problems with VirtualBox. Until containerization actually works properly and provides a good developer experience, I can't see myself switching unless forced.

Re: Ansible 4.0

#28

Post by UI_at_80x24 »

zmmmmm wrote: post #12

I know Ansible has a huge number of fans but I am genuinely curious about the future. That is, I've been trying to figure out where ansible fits in the bigger picture of the modern trend towards IaC. Is it in conflict with that because of its semi-imperative nature? Or is what it does an essential piece of how IaC needs to work to do declarative infrastructure management? I see that for example you can use ansible wi…

I want to love it more then I do. I think it doesn't fit my needs quite enough. When setting up a new system for a LAMP role, it might save me 5 minutes of work. When upgrading/updating my herd of LAMP servers, it might save me 5 minutes, and general 'management' of 50+ LAMP servers all in different AWS regions it's very handy. I like it. I just don't use it often enough to justify it.

I honestly spend more time getting it setup, testing, and deploying then I do using it. In my heart I know that this is the right approach, and the way I should be managing my servers. But the time-saved just isn't there. The consistency is awesome.

I have 2 complaints about Ansible. (1) Minor annoyance - It's slow. It's as slow as if I were sending individual commands from SSH. A scripted solution that is as slow as my typing is a hard sell. It doesn't make spelling mistakes but it does make different mistakes. I can live with this annoyance, but I have literally spun up a new server, SSH'd in, created my Ansible user, and launched my "Initial Server deployment script", went for lunch; and came back to it just finishing.

That example is even excusable. But a simple script: "check for system updates & report back if needed" for 50 servers is slow as fuck. Running them in parallel would be better.

My biggest most scornful vehement hatred is for yml files and python being white-space sensitive. I will piss on the shoes of the person that ever thought of that. Fuck them. Even though I have vim templates for .yml, Even though I have 'turn tabs to spaces', even though I have whitespace characters SHOWN; There is ALWAYS atleast one someplace.

I hold a hatred that only Khaan can feel towards Kirk about this.

But other then that, I really want to love it.

Re: Ansible 4.0

#29

Post by oneplane »

coldtea wrote: post #10
oneplane wrote: post #6

Earlier quoted context omitted.

We have a word that describes that better than 'final': release. And if it's on physical media, you could even call it GM (Golden Master). They are not words that stand on their own, you would combine it with the artifact name and the version you are releasing. Release of the following: Name: ansible Version: 4.0.0 Combined, it's the "Ansible 4.0.0 Release" in whatever order makes sense. If you have something that is…

> We have a word that describes that better than 'final': release. The release would still be 4 even when it's in beta or alpha stage, so no.

beta would be 4.0.0b or 4.0.0-1 or 4.0.0-BETA. But context is important here; it's not called final because it's the final major 4 version but because this is the 'release' version of major version 4 according to the mailing list.

Re: Ansible 4.0

#30

Post by mtlynch »

>Due to a limitation in pip, if you are upgrading from Ansible 3 (or earlier), you need to uninstall Ansible and Ansible Base before installing Ansible 4:

Does anyone know what they're talking about? This is a pain to deal with in my app, and I've never seen it with any other pip package.

Post reply on HN