Plans for 0.5 ("Amsterdam") -- short and long term

Wham bam, Amsterdam.

0.5 now begins. Here is what's going to happen over the next week and beyond.

There are a good set of pull requests to merge in. Some may merge in
soon, the rest within a week or so, as I need to test some things as I
go.

Playbook refactoring will happen over the course of the next week. As
this happens, I do *not* recommend anyone send any patches to
playbooks, as I will not be able to merge them in. I hate to reject
this stuff, so I'm just saying this now. Things are going to get
shaken up a lot in the code (not in the language, language remains
100% the same!)

Goals here are to make the playbook code much easier to follow, but
also more extensible. Playbooks.py and the API interface used by
/usr/bin/ansible-playbook should remain intact, though we'll have
classes for plays, tasks, handlers, and such. One of the things this
will enable is to ask "which files will be used by this playbook"
(ideally), what modules (etc), which can be used for some
optimizations in runner later. This will definitely result in a
playbooks subpackage and can possibly be used for performance tweaks
and maybe even output upgrades later. It will also make things much
more accessible to new contributors, and SHOULD (but might not) also
shrink the code down some.

After playbooks get organized, similar refactoring things may or may
not happen to runner. I have yet to decide if runner starts using a
"task" object internally, but it probably will, while still keeping
the /usr/bin/ansible API signature. This will allow more sharing of
logic between playbook and runner than now, also making performance
things easier.

On another note, a major part of 0.5 will be trying out libssh2 and
seeing if we want to adopt it as a default instead of paramiko --
Matthew Williams has done a lot of good work here and I think there's
a good chance of that -- it's a native C library with a python wrapper
and looks to do all we want. If this happens, it may lead to a need
to want to package libssh2 for EPEL. It promises some speed
improvements but I need to try it first hand. It's already available
in other distros.

The current list of open tickets (many already have pull requests) on
0.5 are here:

https://github.com/ansible/ansible/issues?milestone=5&page=1&state=open

And as usual, whatever comes along the way is also fair game.

Looking forward to this one tremendously, hope you are too!

--Michael

Wham bam, Amsterdam.

0.5 now begins. Here is what's going to happen over the next week and beyond.

[snip]

On another note, a major part of 0.5 will be trying out libssh2 and
seeing if we want to adopt it as a default instead of paramiko --
Matthew Williams has done a lot of good work here and I think there's
a good chance of that -- it's a native C library with a python wrapper
and looks to do all we want. If this happens, it may lead to a need
to want to package libssh2 for EPEL. It promises some speed
improvements but I need to try it first hand. It's already available
in other distros.

Does that mean it will be able to use GSSAPI? That would be a welcome addition.

/andreas

No idea, the top Google hits are from 2007 and say no: http://www.libssh2.org/mail/libssh2-devel-archive-2007-06/0032.shtml

It looks like that work may need to be done in addition to libssh2, however that works.

I will let everybody know when it’s merged in to the right directory structure so that those interested can attempt to get that working.

–Michael