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

31–40 of 141 posts

Re: Ansible 4.0

#31

Post by colechristensen »

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…

The reason why kubernetes et al. are so popular is that the orchestration tools like ansible, puppet, salt, chef... they all failed to deliver ultimately great software. Plagued by mediocre quality external modules and a constant churn of semi-backwards incompatible changes which required frequent maintenance, they have just been hard to use.

You ended up with lots of magic an internal domain knowledge about how to do things, and often had to get clever to get the result you wanted. They were often somewhere both not opinionated and too opinionated, and generally suffered from being "DSL"s domain-specific languages which were really just syntatic magic in various languages which really needed to be actual programming languages or more explicitly policy setting frameworks. They were in the middle of several extremes and tried to be lots of things at once and generally just didn't do a great job, unfortunately.

Re: Ansible 4.0

#32

Post by oneplane »

kbenson wrote: post #24
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…

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 fin…

Final has a finality to it as you somewhat pointed out ;-)

Perhaps, the best option would have been to omit any wording:

release 4.0.0 would be the real version

release 4.0.0-beta would be the beta version

release 4.0.0-rc1 would be the first release candidate

Then again, words like 'final' and 'release' have too many meanings. Release doesn't mean version or 'no longer secret' but mostly 'available for people that just want to use it'. It's probably (like GM) mostly originated from the times where software versions required distribution management with physical aspects which makes 'release' have more of a meaning.

Re: Ansible 4.0

#33

Post by ytjohn »

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…

It's hard to say. I don't see too much point in running Ansible inside Terraform or Terraform inside Ansible (yes, you can go either way). Ansible lagged for years on its support of kubernetes and helm (it had it, but it didn't work). Now (like in the last 12 months) got good support for both, but it might be too late. Terraform has the majority of mind share when it comes to Kubernetes support.

If you're only doing AWS or Google Cloud, Ansible can do that. Whether it does it better or worse than Terraform is all dependent on your use case.

If you're doing anything on premise, or outside of GCP/AWS, Ansible can do that as well. From the using OOB management (HP iLO/Dell iDRAC) to install the OS, to configuring vmware clusters to deploying k8s to declaring resources within k8s. Got network switches and firewalls at your office? You can manage that with Ansible. If you have a bunch of edge compute, Ansible can manage that as well.

What it comes down to is if you've got teams working with anything outside of AWS/GCP. They'll probably be using Ansible, and since you've already go Ansible knowledge across your organization, it would make sense to leverage that expertise and Ansible's cloud integrations.

All of that said - Terraform is much more popular when it comes to the major cloud platforms. If all you have is cloud, then you'll probably start with Terraform and stay there.

https://github.com/ansible-collections/community.kubernetes https://www.ansible.com/integrations/cloud/amazon-web-servic... https://www.ansible.com/integrations/cloud/google-cloud-plat... https://www.ansible.com/integrations/networks

Re: Ansible 4.0

#34

Post by kbenson »

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…

> It's not exactly clear how can Perl programs or shell scripts or Makefiles from 20 years ago play perfectly fine unchanged, but the syntax of a manifest or playbook that does a couple of simple operations cannot remain stable.

It's clear when you deal with both types of systems. Perl optimized for stability and backwards compatibility at the cost of new features and new language conveniences. This is great and a strength when all your competitors are playing catch-up or don't have enough market share to make an impact, but once that's not the case, anything new they bring to the table is a point in their favor, and you get what we have now, the long slow death of Perl.

Backwards compatibility is wonderful until there's a really useful feature that it prevents, then all of a sudden it's a more complex story because it's not just preventing busywork, it's preventing progress.

Re: Ansible 4.0

#35

Post by kungfufrog »

purpleidea wrote: post #23
blcknight wrote: post #11

Earlier quoted context omitted.

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

Hey there, I've been following "mgmt" for years, hoping it was going to be the next big thing. I did see a while ago that you made a significant investment in developing mgmt full-time but then didn't see much news out of the community afterwards.

I'm curious whether there's a status update you could provide? I'd love to get involved as I think it truly represents a next generation style config management system, but I also had fears it was dead in the water or not being actively developed!

Re: Ansible 4.0

#36

Post by alanwreath »

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…

This maybe a Frankenstein baby but when I’m dealing with ec2’s I appreciate creating the AMI using Ansible and Packer. Then referencing said AMI from a terraform script. I rarely do this anymore as I’ve moved the majority of infra under Kubernetes but the couple times I did it this way it didn’t feel dirty.

Re: Ansible 4.0

#37

Post by Jedd »

UI_at_80x24 wrote: post #28
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 gett…

Your first concern is addressed by saltstack - they chose an agent based approach, with client subscription, as the default, which makes for a significantly faster experience.

They subsequently offered an ssh-based option for those that wanted the poor performance of Ansible across larger fleets, or where agents were not palatable.

Unfortunately it doesn't address your second concern, as it also uses yml + jinja.

Re: Ansible 4.0

#38

Post by geerlingguy »

mtlynch wrote: post #30

> 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.

Unfortunately due to some things that happened with the way they renamed packages after the split (from ansible to ansible-core and ansible-base), it required a full 'uninstall and reinstall' operation, otherwise Pip gets things a bit confused and the installation breaks completely.

There was a Herculean effort to try to get it to just upgrade cleanly, but in the end it turned out there was no way.

Re: Ansible 4.0

#39

Post by yawaramin »

UI_at_80x24 wrote: post #28
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 gett…

> Running them in parallel would be better.

It does run in parallel by default though: https://docs.ansible.com/ansible/latest/user_guide/playbooks...

Re: Ansible 4.0

#40

Post by dralley »

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.

While I don't have any hard numbers, I would bet a lot of money that any "slowness" of ansible has nothing to do with the use of Python. Everything happens over SSH, that's a lot of network roundtrips.
Post reply on HN