11 ms·

Ansible 4.0

191 points by AJAlabs 5y ago

pabl0rg 5y ago
It was harder than I expected to find the changelog so I’ll leave the link https://github.com/ansible-community/ansible-build-data/blob/main/4/CHANGELOG-v4.rst https://github.com/ansible-community/ansible-build-data/blob...
- blondin 5y ago
  checked the release notes and it seems like they still don't allow you to run ansible with "python -m". that would have fixed a few issues with virtual environments.
keyle 5y ago
I always cringe when I read the word 'final'. :) Too many years in the industry with projects called final... Basically a tag saying 'this shit ain't never gonna be over! Run for the hills!'. And nothing is more set in stone than a bunch of yml ;) /s
- pram 5y ago
  Final as in it's the actual release and not a candidate, not that it's the final version of Ansible jfyi
  - oneplane 5y ago
    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 not a release, then you would not call it a release. But if you think you are close to a release and you want to be sure, you could state that this is a candidate but not entirely sure. You can even have multiple incarnations of candidates. You end up with a "release candidate" and you could suffix it with number if you have more than one. While many creators and vendors some up with all sorts of schemes, there are a few standards available with extensive documentation like https://semver.org https://semver.org or simply mimic what well-respected projects are using. The problem is of course that nobody agrees on anything if you have a large quantity of things (including large quantity of people), and the urge to create 'a standard to fix the mess' which just adds to the mess in the end. This whole thing is of course not all that important in the grand scheme of things, and an intersection of the 'standards' XKCD commic and 'everything is great and nobody is happy' seems to be where we end up every time.
    - coldtea 5y ago
      >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.
      - oneplane 5y ago
        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.
    - kbenson 5y ago
      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.
      - oneplane 5y ago
        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.
- coldtea 5y ago
  You keep using the word final. I don't think it means what you think it means... Here it doesn't mean "the project is done, no more development". It just means this is the official release of version 4.0 - e.g. no more betas, etc.
- keyle 5y ago
  Well, I'm sorry it seems no one could get my sarcasm today. I know how semver works and I found the final naming ironic.
encryptluks2 5y ago
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.
- grosswait 5y ago
  I doubt building ansible in go or rust we save more than a few ms in the average playbook run.
- blcknight 5y ago
  mgmt config is written in go and has a lot of interesting concepts.
  - purpleidea 5y ago
    Thanks for looking out for us =D Link for any who's interested: https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ I and others have been working quite hard on it, so please come join us =D
    - kungfufrog 5y ago
      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!
- nerdbaggy 5y ago
  salt has been great for me. SSH is just so slow compared to always on zeromq
  - 5y ago
zmmmmm 5y ago
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 within terraform. Do people really do that and is it useful? Or is it something you would only do if you have a lot of legacy infrastructure already configured via Ansible. Curious on the general take here.
- ytjohn 5y ago
  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://github.com/ansible-collections/community.kubernetes https://www.ansible.com/integrations/cloud/amazon-web-services https://www.ansible.com/integrations/cloud/amazon-web-servic... https://www.ansible.com/integrations/cloud/google-cloud-platform https://www.ansible.com/integrations/cloud/google-cloud-plat... https://www.ansible.com/integrations/networks https://www.ansible.com/integrations/networks
- rbjorklin 5y ago
benatkin 5y ago
Ansible is under the GPLv3 but they say this doesn't apply to your .yml files because those are data, not code. I think they're interpreted code. The yml has steps which aren't too different from statements. If what the project creator says matters, the GPL has less legal meaning. I personally think the GPLv3 does protect more than just compiled code, and that Ansible is off their rocker with the GPL.
- yjftsjthsd-h 5y ago
  If it's interpreted and not compiled, then when would it matter? It never creates a derivative work that contains code from you and from ansible. Edit: For that matter, ansible only runs on your own local machine. Without redistribution, the GPL doesn't really have teeth anyway.
aduitsis 5y ago
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 both Ansible and Puppet in my previous job, and we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would, in addition to the other "usual" dangers, bring along the danger of the new version not having a package for the "old" version of Puppet or Ansible that we were using. Which would force us to divert attention to the automation tool's problems instead of using the automation tool to solve problems. I do understand that nothing can stand still and everything must evolve and change, but at some point this acquires the flavour of changes for the sake of changes. Especially when regressions happen and things that were working perfectly are now breaking, it is not exactly pleasant to have to devote time to them. 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 not like those tools were created yesterday, in which case it would be reasonable to expect changes in their first years.
- AJAlabs 5y ago
  With verison 4.0.0, they've implemented semantic versioning which should make life easier for avoiding breaking backwards compatibility changes. https://semver.org https://semver.org
  - asiachick 5y ago
    Does that make it easier or does it just mean you'll be more aware upfront that to get the security fixed or support you need for some new feature you need to upgrade to an incompatible version
  - jacobsenscott 5y ago
    All semver does is tell you you are pinned to some obsolete tool, and you are going to go through a soul sucking 6 months of yak shaving to stay up to date. (rails programmer since v3 here) Semver doesn't make life easier. Making backward compatible changes is what makes life easier.
VectorLock 5y ago
Is there any big improvements or whats the benefit of porting to Ansible 4 (other than it seems Ansible 3 is EOL'd now)
lobo_tuerto 5y ago
Link to previous discussion: https://news.ycombinator.com/item?id=27215477 https://news.ycombinator.com/item?id=27215477
mtlynch 5y ago
>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.
- geerlingguy 5y ago
  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.
  - mtlynch 5y ago
    Ah, gotcha. Thanks for the clarification, Jeff!
0xbadcafebee 5y ago
"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" Was it really a limitation in Pip? Or did the Ansible devs just really want this non-backwards-compatible release to use the same name as before, just so they wouldn't have to use a new package name like "ansible4"? Even though that would allow both pre-ansible4 and ansible4 scripts to co-exist? And considering everybody has to test and update their code for ansible 4 anyway?? This seems to just cause more pain for devs and admins with no real benefit. Which is to say, par for the course. This is the main reason I have always hated using Ansible. Arbitrary decisions leading to a cumbersome, bloated, undocumented, difficult mess.
secondcoming 5y ago
This broke us. Some crap about sftp. Three hours down the drain.
- Spivak 5y ago
  Why are you blindly upgrading? The only safe way to use Ansible in production or on a team is to pin the version everyone uses because even minor releases can break playbooks and change behavior.
  - secondcoming 5y ago
    I'm not sure of the details, but it has something to do with the modern way of CI/CD pulling in random 3rd party docker containers.
    - r1cka 5y ago
      Sounds like your docker was pulling latest instead of a versioned tag. I'd update that and be happy this only cost you a few hours.
shaicoleman 5y ago
Their versioning is unnecessarily confusing. Why call it version 4 and then when you run --version it shows a different version? $ ansible --version ansible [core 2.11.0] $ python -c 'from ansible_collections.ansible_release import ansible_version; print(ansible_version)' 4.0.0
- Spivak 5y ago
  Because after Ansible 2.9 they made a huge change in how module resolution works and put most of the modules in a separate repository to be versioned independently.
polskibus 5y ago
Does anyone use Ansible in GitOps ? If so, what other tools do you use? Gitlab? Other? If not, what would you recommend for non-Kubernetes infrastructure for GitOps?
InitEnabler 5y ago
Is there any open source alternatives to Ansible, Terraform, Chef, Puppet, etc?

191 points by AJAlabs 5y ago

It was harder than I expected to find the changelog so I’ll leave the link https://github.com/ansible-community/ansible-build-data/blob/main/4/CHANGELOG-v4.rst https://github.com/ansible-community/ansible-build-data/blob...

blondin 5y ago
checked the release notes and it seems like they still don't allow you to run ansible with "python -m". that would have fixed a few issues with virtual environments.

keyle 5y ago

I always cringe when I read the word 'final'. :) Too many years in the industry with projects called final... Basically a tag saying 'this shit ain't never gonna be over! Run for the hills!'. And nothing is more set in stone than a bunch of yml ;) /s

pram 5y ago
Final as in it's the actual release and not a candidate, not that it's the final version of Ansible jfyi
- oneplane 5y ago
  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 not a release, then you would not call it a release. But if you think you are close to a release and you want to be sure, you could state that this is a candidate but not entirely sure. You can even have multiple incarnations of candidates. You end up with a "release candidate" and you could suffix it with number if you have more than one. While many creators and vendors some up with all sorts of schemes, there are a few standards available with extensive documentation like https://semver.org https://semver.org or simply mimic what well-respected projects are using. The problem is of course that nobody agrees on anything if you have a large quantity of things (including large quantity of people), and the urge to create 'a standard to fix the mess' which just adds to the mess in the end. This whole thing is of course not all that important in the grand scheme of things, and an intersection of the 'standards' XKCD commic and 'everything is great and nobody is happy' seems to be where we end up every time.
  - coldtea 5y ago
    >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.
    - oneplane 5y ago
      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.
  - kbenson 5y ago
    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.
    - oneplane 5y ago
      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.
coldtea 5y ago
You keep using the word final. I don't think it means what you think it means... Here it doesn't mean "the project is done, no more development". It just means this is the official release of version 4.0 - e.g. no more betas, etc.
keyle 5y ago
Well, I'm sorry it seems no one could get my sarcasm today. I know how semver works and I found the final naming ironic.

encryptluks2 5y ago

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.

grosswait 5y ago
I doubt building ansible in go or rust we save more than a few ms in the average playbook run.
blcknight 5y ago
mgmt config is written in go and has a lot of interesting concepts.
- purpleidea 5y ago
  Thanks for looking out for us =D Link for any who's interested: https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ I and others have been working quite hard on it, so please come join us =D
  - kungfufrog 5y ago
    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!
nerdbaggy 5y ago
salt has been great for me. SSH is just so slow compared to always on zeromq
- 5y ago

zmmmmm 5y ago

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 within terraform. Do people really do that and is it useful? Or is it something you would only do if you have a lot of legacy infrastructure already configured via Ansible. Curious on the general take here.

ytjohn 5y ago
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://github.com/ansible-collections/community.kubernetes https://www.ansible.com/integrations/cloud/amazon-web-services https://www.ansible.com/integrations/cloud/amazon-web-servic... https://www.ansible.com/integrations/cloud/google-cloud-platform https://www.ansible.com/integrations/cloud/google-cloud-plat... https://www.ansible.com/integrations/networks https://www.ansible.com/integrations/networks
rbjorklin 5y ago

benatkin 5y ago

Ansible is under the GPLv3 but they say this doesn't apply to your .yml files because those are data, not code. I think they're interpreted code. The yml has steps which aren't too different from statements. If what the project creator says matters, the GPL has less legal meaning. I personally think the GPLv3 does protect more than just compiled code, and that Ansible is off their rocker with the GPL.

yjftsjthsd-h 5y ago
If it's interpreted and not compiled, then when would it matter? It never creates a derivative work that contains code from you and from ansible. Edit: For that matter, ansible only runs on your own local machine. Without redistribution, the GPL doesn't really have teeth anyway.

aduitsis 5y ago

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 both Ansible and Puppet in my previous job, and we always found it mildly annoying that upgrading a system (Linux, FreeBSD) would, in addition to the other "usual" dangers, bring along the danger of the new version not having a package for the "old" version of Puppet or Ansible that we were using. Which would force us to divert attention to the automation tool's problems instead of using the automation tool to solve problems. I do understand that nothing can stand still and everything must evolve and change, but at some point this acquires the flavour of changes for the sake of changes. Especially when regressions happen and things that were working perfectly are now breaking, it is not exactly pleasant to have to devote time to them. 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 not like those tools were created yesterday, in which case it would be reasonable to expect changes in their first years.

AJAlabs 5y ago
With verison 4.0.0, they've implemented semantic versioning which should make life easier for avoiding breaking backwards compatibility changes. https://semver.org https://semver.org
- asiachick 5y ago
  Does that make it easier or does it just mean you'll be more aware upfront that to get the security fixed or support you need for some new feature you need to upgrade to an incompatible version
- jacobsenscott 5y ago
  All semver does is tell you you are pinned to some obsolete tool, and you are going to go through a soul sucking 6 months of yak shaving to stay up to date. (rails programmer since v3 here) Semver doesn't make life easier. Making backward compatible changes is what makes life easier.

VectorLock 5y ago

Is there any big improvements or whats the benefit of porting to Ansible 4 (other than it seems Ansible 3 is EOL'd now)

lobo_tuerto 5y ago

Link to previous discussion: https://news.ycombinator.com/item?id=27215477 https://news.ycombinator.com/item?id=27215477

mtlynch 5y ago

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

geerlingguy 5y ago
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.
- mtlynch 5y ago
  Ah, gotcha. Thanks for the clarification, Jeff!

0xbadcafebee 5y ago

"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" Was it really a limitation in Pip? Or did the Ansible devs just really want this non-backwards-compatible release to use the same name as before, just so they wouldn't have to use a new package name like "ansible4"? Even though that would allow both pre-ansible4 and ansible4 scripts to co-exist? And considering everybody has to test and update their code for ansible 4 anyway?? This seems to just cause more pain for devs and admins with no real benefit. Which is to say, par for the course. This is the main reason I have always hated using Ansible. Arbitrary decisions leading to a cumbersome, bloated, undocumented, difficult mess.

secondcoming 5y ago

This broke us. Some crap about sftp. Three hours down the drain.

Spivak 5y ago
Why are you blindly upgrading? The only safe way to use Ansible in production or on a team is to pin the version everyone uses because even minor releases can break playbooks and change behavior.
- secondcoming 5y ago
  I'm not sure of the details, but it has something to do with the modern way of CI/CD pulling in random 3rd party docker containers.
  - r1cka 5y ago
    Sounds like your docker was pulling latest instead of a versioned tag. I'd update that and be happy this only cost you a few hours.

shaicoleman 5y ago

Their versioning is unnecessarily confusing. Why call it version 4 and then when you run --version it shows a different version? $ ansible --version ansible [core 2.11.0] $ python -c 'from ansible_collections.ansible_release import ansible_version; print(ansible_version)' 4.0.0

Spivak 5y ago
Because after Ansible 2.9 they made a huge change in how module resolution works and put most of the modules in a separate repository to be versioned independently.

polskibus 5y ago

Does anyone use Ansible in GitOps ? If so, what other tools do you use? Gitlab? Other? If not, what would you recommend for non-Kubernetes infrastructure for GitOps?

InitEnabler 5y ago

Is there any open source alternatives to Ansible, Terraform, Chef, Puppet, etc?