I hope open sourcing Ansible Tower is still on the cards after it was promised at a conference shortly after acquisition.
Ansible 2.1 Released, with Network Automation, Containers
11–20 of 94 posts
Re: Ansible 2.1 Released, with Network Automation, Containers
#12I love Ansible, and have been using it since it was a humble little git repo with a single author. Unfortunately it's probably the most important python package that doesn't support Python 3, it would be cool to see it upgraded. Apparently the hold-up is supporting very old 2.x python versions because of RHEL.
I think it actually makes sense for something like Ansible to use Python 2 because it's about controlling lots of remote machines on various Linux distros, and the idea is that it's agentless. If you suddenly have to install an "agent" (Python 3) on all the remote machines before you control them with Ansible, that wouldn't be great.
On the other hand, Ansible itself could have a tiny bootstrap step which installs Python 3 on all the remote machines before it does any work.
In our case, we use Ansible daily for deployments, but haven't actually written any custom Python modules -- it's all just straight Ansible YAML. So I'm guessing for a lot of use cases it doesn't really matter what language Ansible is written in.
Re: Ansible 2.1 Released, with Network Automation, Containers
#13Unarchive module gets cert error on get.docker.com on Ubuntu 14.04 LTS. System Python is too old.
Re: Ansible 2.1 Released, with Network Automation, Containers
#14Earlier quoted context omitted.
The simple answer is: you don't, you "roll forward." In the event you deploy some code, a DB migration, a server configuration change, etc, and your solution fails after the fact, you move forward, not backwards. Let me explain further. If you deploy v1.0 of your application and it works, great! If you then deploy v1.1 and it falls over, you find out why, apply a fix, test it locally (Vagrant?), deploy it to a testin…
Curious if "roll forward only" could create situations where a failed version change could place the system of interest in a non-functional state until the problem was diagnosed, the code revised, and an update released. If that's possible, I would have concerns about the infrastructure meeting the core needs of the business such as providing value to cutomers.
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 with configuration management, infrastructure as code (Terraform), and tests, not to mention three environments (development,test, stage - at minimum) to work your way through before pushing to production.
Re: Ansible 2.1 Released, with Network Automation, Containers
#15I love Ansible, and have been using it since it was a humble little git repo with a single author. Unfortunately it's probably the most important python package that doesn't support Python 3, it would be cool to see it upgraded. Apparently the hold-up is supporting very old 2.x python versions because of RHEL.
I think it actually makes sense for something like Ansible to use Python 2 because it's about controlling lots of remote machines on various Linux distros, and the idea is that it's agentless. If you suddenly have to install an "agent" (Python 3) on all the remote machines before you control them with Ansible, that wouldn't be great. On the other hand, Ansible itself could have a tiny bootstrap step which installs Py…
Or, they could support both so that they can be an agent for distros that won't have python2 installed and only python3 (AFAIK they don't exist yet).
Re: Ansible 2.1 Released, with Network Automation, Containers
#16Can anyone comment on the speed of Ansible 2+?
I have a bunch of playbooks that still use 1.8 and they are dog slow. Changing the contents of one file can take ~10 minutes. (Interestingly, running the entire playbook on a clean server is actually faster).
Re: Ansible 2.1 Released, with Network Automation, Containers
#17Earlier quoted context omitted.
I think it actually makes sense for something like Ansible to use Python 2 because it's about controlling lots of remote machines on various Linux distros, and the idea is that it's agentless. If you suddenly have to install an "agent" (Python 3) on all the remote machines before you control them with Ansible, that wouldn't be great. On the other hand, Ansible itself could have a tiny bootstrap step which installs Py…
Or, they could support both so that they can be an agent for distros that won't have python2 installed and only python3 (AFAIK they don't exist yet).
Ubuntu Server no longer has Python 2 installed by default (though it's available if you want it). This is the case on 16.04.
Re: Ansible 2.1 Released, with Network Automation, Containers
#18Earlier quoted context omitted.
I think it actually makes sense for something like Ansible to use Python 2 because it's about controlling lots of remote machines on various Linux distros, and the idea is that it's agentless. If you suddenly have to install an "agent" (Python 3) on all the remote machines before you control them with Ansible, that wouldn't be great. On the other hand, Ansible itself could have a tiny bootstrap step which installs Py…
Or, they could support both so that they can be an agent for distros that won't have python2 installed and only python3 (AFAIK they don't exist yet).
The latest Ubuntu LTS 16.04 only has Python3 installed by default.
For Ansible modules to run at all, you need to install Python 2 first (possibly using "pre_tasks" + a "raw:" command in your Ansible playbook)
Re: Ansible 2.1 Released, with Network Automation, Containers
#19Can anyone comment on the speed of Ansible 2+? I have a bunch of playbooks that still use 1.8 and they are dog slow. Changing the contents of one file can take ~10 minutes. (Interestingly, running the entire playbook on a clean server is actually faster).
>Changing the contents of one file can take ~10 minutes.
O_o
That kind of simple operation just zipped by for me on Ansible 1.6, 1.8, 1.9, and 2.0. The only noticeably slow kinds of operations for me are generally the package installs (understandably). I don't use a ton of variables in my templates, though.
Re: Ansible 2.1 Released, with Network Automation, Containers
#20Earlier quoted context omitted.
Curious if "roll forward only" could create situations where a failed version change could place the system of interest in a non-functional state until the problem was diagnosed, the code revised, and an update released. If that's possible, I would have concerns about the infrastructure meeting the core needs of the business such as providing value to cutomers.
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…
Why not just roll back while you're testing the fix? No need to be suffering unnecessary downtime while you hunt, fix, test, package, stage, and deploy the hotfix. Rolling back takes you to a version that has already passed all stages.