Hey everyone, just dropping a short status update on the progress on getting
Ansible running on python3.
Bad news first: I don't think that Ansible-2.2 on python3 will be production
ready. There are large pieces of the controller side code that I haven't yet
looked at or tested heavily and the feature freeze is just around the corner
(september 5th). So there's definitely going to be bugs in the
Python3-on-controller support. Some of them could quite possibly be major
enough and invasive enough to fix that we will want to fix them in Ansible-2.3
instead of Ansible 2.2.x so that we don't destabilize other parts of Ansible.
That said, I do think there will be enough Python3 support that we can
realistically call it a Tech Preview. Here's a few of the things that are
working today:
* The local connection plugin is working pretty well.
* The ping module is working.
* /usr/bin/ansible is working.
This means that you can check out the devel branch right now and do:
$ source ./hacking/env-setup
$ python3 bin/ansible localhost -m ping *[py3-ssh-1] (17:59:58)
[WARNING]: provided hosts list is empty, only localhost is available
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}
Amazing right? And for more thrills, you'll find that passing unicode values
is also working:
$ python3 bin/ansible localhost -m ping -a 'data=café' *[py3-ssh-1] (18:00:04)
[WARNING]: provided hosts list is empty, only localhost is available
localhost | SUCCESS => {
"changed": false,
"ping": "café"
}
... but wait, there's more!
* Parsing of yaml is also working.
* Parsing of inventory is working so far although this is one of the places
where more testing is sure to turn up bugs.
* Handling of command line options also seems to be working for the few simple
things I've tested.
* sudo is working!
* A handful of modules have been ported and maybe a dozen others appear to be
working out of the box.
With that set of things, you can also run playbooks:
---
- hosts: localhost
tasks:
- copy:
src: /etc/os-release
dest: /var/tmp/release
mode: 0600
- stat:
path: /var/tmp/release
register: release_stat
- debug:
var: release_stat
- command: echo 'Hello world!'
ansible-playbook test.yml -e 'ansible_python_interpreter=/usr/bin/python3 -vvv
I don't think that enough modules are currently working to be able to manage a
production infrastructure using just python3 capable modules. But there are
enough that we've been able to start turning on integration tests for modules
on python3. for instance, here's a recent run of the known good subset of
integration tests on a VM with only python3 installed:
[https://app.shippable.com/runs/57be39613d3c340e0003c341/30/console](https://app.shippable.com/runs/57be39613d3c340e0003c341/30/console)
... But wait, there's more!
Sometime in the next few days, I'm hoping to get this PR kicked into shape and
merged into devel: [https://github.com/ansible/ansible/pull/17234](https://github.com/ansible/ansible/pull/17234) The PR is to
port the ssh connection plugin to python3. Once that's in you will be able to
use the limited set of modules that are ported to do work on remote machines
that have python3. That's not where we need to be to manage production
infrastructure but it is enough for people to be able to do real work with the
code as they're playing around with it. Things like using the command module
to run quick ad hoc tasks on a few dozen servers should be possible at that
point which should make it easier to try out Ansible on python3 and give
feedback.
So what can you do to help out? Three answers:
(1) between now and September 5th I'm going to be working very hard at porting
more code to python3. If you'd like to work on more features central to
how Ansible operates (roles, inventory, etc), this is the window to test
what's working, propose invasive bugfixes, and port core functionality
over.
(2) From September 5th until the rc's start we can still merge self-contained
changes. Porting of more modules or auxiliary connection plugins can
happen during this time. What we can't do is merge things that radically
alter any basic assumptions. For instance, it will likely be too late to
merge code that changes the type of a widely used file path from bytes to
str at that point.
(3) During the rcs. We'll be concentrating on bugs, bugs, bugs. We may still
port some modules and plugins but we wouldn't want to work on something
central to many people's lives like copy or paramiko.
And concurrent to the rc process -- We'll also have split the stable-2.2 branch
from the devel branch at that point. So if someone wants to work on some more
intrusive changes those can land in the devel tree at that time.
If you want to work on any of this, feel free to file PRs and then ping me on
IRC so I know to review and merge it -- I'm abadger1999 on [irc.freenode.net](http://irc.freenode.net).
I'm usually watching #ansible-devel whenever I'm awake (I'm in the US Pacific
Timezone) and will catch up on IRC backlog when I wake up.
Thanks and happy hacking!
-Toshio
So I have been trying that, and while indeed, we can't run a complete
infrastructure yet, there is only a few type of errors to fix.
One of the easiest is iteritems vs items on python 3, which requires
this kind of fix:
https://github.com/ansible/ansible-modules-core/pull/4576
It should be easy to find the place that need a fix with grep (on
iteritems, iterkeys, itervalues)
There is various strings/unicode issues, who can be more tricky, but
most of the time, that's just using "to_native" at the right place:
https://github.com/ansible/ansible-modules-core/pull/4556
https://github.com/ansible/ansible-modules-core/pull/4560
Also, if you do testing, I would recommend to test idempotence, and more
than just a single run. I stumbled on
https://github.com/ansible/ansible-modules-core/pull/4559/files the code
was working, but it was no longer idempotent.
The last type of issue I did see is with filter, who no longer return a
list, so we have to be explicit when using it, see one of the fix on
https://github.com/ansible/ansible-modules-core/pull/4496/files
With the various PR to fix that are on github, I was able to
successfully deploy a few non trivial roles on Fedora 24.