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

**URL:** <https://forum.ansible.com/t/plans-for-0-5-amsterdam-short-and-long-term/11573>\
**Category:** Ansible Project\
**Created:** [May 24, 2012, 12:20am UTC](https://forum.ansible.com/t/plans-for-0-5-amsterdam-short-and-long-term/11573 "2012-05-24T00:20:08Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [May 24, 2012, 12:20am UTC](https://forum.ansible.com/t/plans-for-0-5-amsterdam-short-and-long-term/11573/1 "2012-05-24T00:20:08Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![Andreas\_Davour](https://avatars.discourse-cdn.com/v4/letter/a/bcef8e/32.png) [@Andreas\_Davour](https://forum.ansible.com/u/Andreas_Davour)\
**Post date:** [May 24, 2012, 9:00am UTC](https://forum.ansible.com/t/plans-for-0-5-amsterdam-short-and-long-term/11573/2 "2012-05-24T09:00:06Z")

</div>

> 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

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [May 24, 2012, 11:39am UTC](https://forum.ansible.com/t/plans-for-0-5-amsterdam-short-and-long-term/11573/3 "2012-05-24T11:39:52Z")

</div>

No idea, the top Google hits are from 2007 and say no: [http://www.libssh2.org/mail/libssh2-devel-archive-2007-06/0032.shtml](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
