ANSIBLE UPDATEV2 AND BEYOND

JAMES CAMMARATA

ABOUT MEDirector of Ansible Core Engineering

Started contributing to Cobbler in September of 2008, and tookover the project leadership in 2010

Joined Ansible in July, 2013

WHY V2?

TECHNICAL DEBTAnsible has grown organically at a very rapid rate for 3+ years.Some early design descisions have had additional featuresbolted on without concern for the overall system architecture.It was getting to the point where it was difficult to fix bugsand/or add new features without things breaking inunexpected ways.Difficulty of testing, especially in terms of python unit tests, didnot help.

NEW FEATURES IN V2:

IMPROVED ERROR MESSAGESPlaybook errors not related to syntax will (in most cases) stillshow the file along with the line and column where the error

occurred.

IMPROVED ERROR EXAMPLE:ERROR! no action detected in task

The error appears to have been in '/path/to/bad/playbook/site.yml':line 4, column 16, but may be elsewhere in the file depending on theexact syntax problem.

The offending line appears to be:

tasks: - bad_module: ̂ here

BLOCKSProvides a method for catching errors during task execution,as well as an option to always execute some set of tasksregardless of whether an exception occurred or not.Allows for easier grouping of related tasks.

BLOCK EXAMPLE:tasks: - block: - command: /bin/false - debug: msg="you shouldn't see me" rescue: - debug: msg="this is the rescue" - command: /bin/false - debug: msg="you shouldn't see this either" always: - debug: msg="this is the always block, it will always be seen"

NESTED BLOCK EXAMPLE:tasks: - block: - block: - block: - block: - debug: msg="Yes, this really works (but try not to do it too much)"

BLOCKS MAKE GROUPING RELATED TASKS EASIERtasks:- block: - debug: msg="task 1" - debug: msg="task 2" when: foo != "some value" tags: - do_tasks

EXECUTION STRATEGY PLUGINSAllows changes in the way tasks are executed:

linear - traditional Ansible, which waits for all hosts tocomplete a task before continuingfree - allows each host to process tasks as fast as possible,without waiting for other hostsAnd anything else people can conceive - just write a new pluginfor it!

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

EXECUTION-TIME EVALUATION OF INCLUDETASKS

Previously, include statements acted like pre-processorstatements and were evaluated/expanded before any tasks

started running.

Should allow the return use of include + with* actions.

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

INCLUDE + WITH EXAMPLE #2:- hosts: all gather_facts: false tasks: - include: "{{inventory_hostname}}.yml some_var={{item}}"

EXTENDED INHERITENCE OF BLOCKS/ROLESValues like `become*` and others are now settable on blocks and

roles, which are then inherited by all tasks contained within.

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

IMPROVED VARIABLE MANAGEMENTA new class (VariableManager) controls the order and source of

variables to avoid flattening things too early.

Playbook objects now use a `post_validate` method, whichtemplates all fields in one shot, as opposed to the piece-meal way

we currently template field values.

BETTER USE OF OOPMore classes, with an emphasis on each class doing one thing

only.

More use of inheritance, especially in the plugin systems.

Well defined interactions between classes.

End-goal is better ability to write unit tests.

WHAT WILL BREAK?

PLAYBOOKSNothing. We are aiming for 100% backwards-compatibility.

INTERNAL APISPlugin APIs are changing. Connection, action, and some others

will be different.

We plan on writing a transition classes and a guide for authors ofplugins, to make it easier to move them to be compatible with V2.

EXAMPLE TRANSITIONAL CLASSfrom distutils.version import LooseVersionfrom ansible import __version__ as __ansible_version__class LookupModule(object): def __new__(class_name, *args, **kwargs): if LooseVersion(__ansible_version__) < LooseVersion("2.0"): from ansible import utils, errors class LookupModuleV1(object): def __init__(self, basedir, *args, **kwargs): self.basedir = basedir def run(self, terms, inject=None, **kwargs): ... else: from ansible.errors import AnsibleError from ansible.plugins.lookup import LookupBase class LookupModuleV2(LookupBase): def run(self, terms, variables=None, **kwargs): ...

V2 STATUS TODAY

Live in the devel branch as of June 1st, 2015

Expected official release of Ansible 2.0 is early to mid-July, 2015

UPCOMING MODULESCHANGES

The 'extras' modules will be come another package to beinstalled. Installations from source will still see it as a submodule.

The 'core' modules repository will be going away, and will againbe part of the main ansible/ansible repository.

QUESTIONS?

THANKS!