Misc housekeeping and notes -- Release 0.8 timetable, freeze dates, tickets by milestone, what's on deck for 0.9

The bug queue for 0.8 is getting to be pretty reasonable. I am
planning on squashing tickets through the weekend so we can deliver
0.8 shortly.

Please review any open bugs and see if you can help squash any of them:

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

Dates for 0.8 release are as follows:

Feature freeze: this Friday 12PM midnight EST ... no new pull
requests for features (bugs are ok)
Testing and any bugfixes: next Monday through Thursday
Release: following Friday night

You will notice I have moved some bugs and feature ideas to 0.9 already.

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

A lot of these are RFEs or borderline RFEs and I'll be dependent on
everyone here to help work on particular issues for 0.9 once 0.9
starts. This is already a pretty large list. RFEs without
volunteers may not all get implemented.

Major 0.9 themes for me in 0.9 will include resurecting
ansible-commander (in part, anyway), the new 'when' keyword (providing
an easier only_if), making a pluggable system for looking up variables
in external systems which jp_mens has already prototyped, and reducing
the number of runner operations for performance operations (like doing
template+file and copy+file all in one module call, and exploring
modules that do directory cleanup versus a seperate tempdir call). I
suspect about a 30-40% reduction in remote operations is possible in
0.9.

So yeah...

--Michael

Sounds nice. But there's one thing, and I mean this in a constructive
way: Prove it.

Metrics. Do you have any data collected showing the current number of
remote operations? A good sample set to collect that from might be the
examples directory.

The graphs need more rounded corners and drop shadows. And graphs.

You can do it now with "-v -v -v".

I've bounced strategies around with skvidal and mgwilliams a fair
amount several months ago so this is mostly just a culmination of
that.

It works roughly like this (as you can see from -v -v -v) today:

Mkdir temp dir
md5sum remote file to decide if we need to copy
Transfer copy module file into tempdir
Run module file
transfer actual file
Transfer flie module file into tempdir (daisy chain second module)
Run module file
Delete tempdir

That's 8 operations. It used to be a little worse before as before
new style modules the args file was a seperate file, and if you are
executing a non-python or old-style module that is still true. Of
course 8 is a bit many here because it's file or template... and if
you are using ControlPersist or whatever it's not terrible, and
there's still the paramiko caching idea thing. But anyway, reducing
runner ops is actually the lowest hanging proverbial fruit.

This could easily be

Mkdir temp dir
md5sum remote file to decide if we need to copy
transfer copy module that knows how to do all file can do because it's
in module common
transfer actual file
run module file and the module file was told where the tempdir was so
it can self delete

That's 5 operations, saving 3. That's a pretty big cut. We can
also eliminate daisy chaining in other places, like the get_url
module, and if we are lucky, eliminate the daisy_chaining part of the
code base altogether (unless we decide to keep it around for
non-Python modules, but I'm drawn on this).

If you are pushing a module that does not require any auxilliary files
and does not daisy chain (such as, say, service), you can break it
down to:

push module to temp /file/ location
transfer module
run module and have it self delete

Which is 3 operations (down from 5 or 6 or so)

When we do this, we'll definitely be collecting benchmarks and I'll
probably even add a mode that keeps benchmark data inside hostvars so
we can do before and afters, and not just wallclock time...

--Michael