This document discusses version 2 (V2) of Ansible, which refactors portions of Ansible's core executor engine to address technical debt. Key changes in V2 include improved error messages, new block and strategy execution plugins, execution-time evaluation of included tasks, and better object-oriented design. The goal is to improve testability and make it easier to add new features without breaking existing functionality. V2 can be tested now and will become the default in March 2015, while Ansible 1.9 will be the last major release using the original code.

1. WHAT'S NEW IN V2
JAMES CAMMARATA
(GITHUB: JIMI-C)

2. ABOUT ME
Director of Ansible Core Engineering
Started contributingto Cobbler in September of 2008, and took
over the projectleadership in 2010
Joined Ansible in July, 2013

3. WHAT IS V2?

4. An effortto refactor portions of Ansible's core executor engine.

5. WHY V2?

6. TECHNICAL DEBT
Ansible has grown organicallyataveryrapid rate for 3 years.
Some earlydesign descisions have had additionalfeatures
bolted on withoutconcern for the overallsystem architecture.
Itwas gettingto the pointwhere itwas difficultto fix bugs
and/or add new features withoutthings breakingin
unexpected ways.
Difficultyof testing, especiallyin terms of python unittests, did
nothelp.

7. NEW FEATURES IN V2:

8. IMPROVED ERROR MESSAGES
Playbook errors notrelated to syntax will(in mostcases) still
show the file alongwith the line and column where the error
occurred.

9. IMPROVED ERROR EXAMPLE:
ERROR!noactiondetectedintask
Theerrorappearstohavebeenin'/path/to/bad/playbook/site.yml':
line4,column16,butmaybeelsewhereinthefiledependingonthe
exactsyntaxproblem.
Theoffendinglineappearstobe:
tasks:
-bad_module:
^here

10. BLOCKS
Provides amethod for catchingerrors duringtask execution,
as wellas an option to always execute some setof tasks
regardless of whether an exception occurred or not.
Currentlyuses syntax similar to Ruby(begin/rescue/always)
butwillprobablybe changed to be more Pythonic
(try/except/finally).

11. BLOCK EXAMPLE:
tasks:
-block:
-command:/bin/false
-debug:msg="youshouldn'tseeme"
rescue:
-debug:msg="thisistherescue"
-command:/bin/false
-debug:msg="youshouldn'tseethiseither"
always:
-debug:msg="thisisthealwaysblock,itwillalwaysbeseen"
when:foo!="somevalue"
tags:
-foo
-bar

12. EXECUTION STRATEGY PLUGINS
Allows changes in the waytasks are executed:
linear -traditionalAnsible, which waits for allhosts to
complete atask before continuing
free -allows each hostto process tasks as fastas possible,
withoutwaitingfor other hosts
And anythingelse people can conceive -justwrite anew plugin
for it!

13. STRATEGY EXAMPLE:
-hosts:all
gather_facts:false
strategy:free
vars:
...
vars_files:
...
tasks:
...

14. EXECUTION-TIME EVALUATION OF INCLUDE
TASKS
Should allow the return use of include + with*actions.

15. INCLUDE + WITH EXAMPLE:
-hosts:all
gather_facts:false
tasks:
-include:foo.ymlsome_var={{item}}
with_items:
-a
-b
-c

16. IMPROVED VARIABLE MANAGEMENT
Anew class (VariableManager) controls the order and source of
variables to avoid flatteningthings too early.
Playbook objects now use a`post_validate` method, which
templates allfields in one shot, as opposed to the piece-mealway
we currentlytemplate field values.

17. BETTER USE OF OOP
More classes, with an emphasis on each class doingone thing
only.
More use of inheritance, especiallyin the plugin systems.
Welldefined interactions between classes.
End-goalis better abilityto write unittests.

18. WHAT WILL BREAK?

19. PLAYBOOKS
Nothing. We are aimingfor 100%backwards-compatibility.

20. INTERNAL APIS
Plugin APIs are changing. Connection, action, and some others
willbe different.
We plan on writingatransition guide for authors of plugins, to
make iteasier to move them to be compatible with V2.

21. WHEN WILL IT BE
READY?

22. V2 CAN BE TESTED TODAY!
$gitclonehttps://github.com/ansible/ansible.git
$cdansible
$.v2/hacking/env-setup
profit!

23. We are targetingMarch 2015 for the switchover on the devel
branch.
Ansible 1.9 willbe released before the switchover, and willbe the
lastmajor release usingthe 'v1'code.
The originalcode willstillbe available in the source tree, with its
own `hacking` scriptavailable should people wish to continue
usingitfrom checkout.

24. SPEAKING OF 1.9...

25. As noted above, we are aimingfor arelease in early-mid March.
This release willprimarilybe aboutbugfixes and new modules in
the "extras"repo, butwillalso introduce supportfor
PowerBroker authentication in addition to su/sudo..
This version willalso introduce the use of officialrelease
candidates for testing.

26. QUESTIONS?

27. THANKS!