V2 of Ansible aims to address technical debt that made the framework difficult to maintain and improve. Key features of V2 include improved error messages, blocks for task grouping, new execution strategies, and better support for variables and object-oriented programming. The changes are designed to be backwards compatible with playbooks while improving testability and flexibility for future development. V2 is currently in development with an expected release in July 2015.

1. ANSIBLE UPDATE
V2 AND BEYOND
JAMES CAMMARATA

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. WHY V2?

4. 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.

5. NEW FEATURES IN V2:

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

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

8. 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.
Allows for easier groupingof related tasks.

9. 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"

10. NESTED BLOCK EXAMPLE:
tasks:
-block:
-block:
-block:
-block:
-debug:msg="Yes,thisreallyworks(buttrynottodoittoomuch)"

11. BLOCKS MAKE GROUPING RELATED TASKS EASIER
tasks:
-block:
-debug:msg="task1"
-debug:msg="task2"
when:foo!="somevalue"
tags:
-do_tasks

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
Previously, include statements acted like pre-processor
statements and were evaluated/expanded before anytasks
started running.
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. INCLUDE + WITH EXAMPLE #2:
-hosts:all
gather_facts:false
tasks:
-include:"{{inventory_hostname}}.ymlsome_var={{item}}"

17. EXTENDED INHERITENCE OF BLOCKS/ROLES
Values like `become*` and others are now settable on blocks and
roles, which are then inherited byalltasks contained within.

18. INHERITENCE EXAMPLE
-hosts:all
gather_facts:false
remote_user:testing
roles:
-{role:foo,become_user:root}
tasks:
-block
-command:whoami
-command:/do/something/privileged
-stat:path=/root/.ssh/id_rsa
become_user:root

19. 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.

20. 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.

21. WHAT WILL BREAK?

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

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

24. EXAMPLE TRANSITIONAL CLASS
fromdistutils.versionimportLooseVersion
fromansibleimport__version__as__ansible_version__
classLookupModule(object):
def__new__(class_name,*args,**kwargs):
ifLooseVersion(__ansible_version__)<LooseVersion("2.0"):
fromansibleimportutils,errors
classLookupModuleV1(object):
def__init__(self,basedir,*args,**kwargs):
self.basedir=basedir
defrun(self,terms,inject=None,**kwargs):
...
else:
fromansible.errorsimportAnsibleError
fromansible.plugins.lookupimportLookupBase
classLookupModuleV2(LookupBase):
defrun(self,terms,variables=None,**kwargs):
...

25. V2 STATUS TODAY

26. Live in the develbranch as of June 1st, 2015
Expected officialrelease of Ansible 2.0 is earlyto mid-July, 2015

27. UPCOMING MODULES
CHANGES

28. The 'extras'modules willbe come another package to be
installed. Installations from source willstillsee itas asubmodule.
The 'core'modules repositorywillbe goingaway, and willagain
be partof the main ansible/ansible repository.

29. QUESTIONS?

30. THANKS!