Upload
jimi-c
View
13.587
Download
1
Embed Size (px)
Citation preview
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
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.
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.Currently uses syntax similar to Ruby (begin/rescue/always)but will probably be changed to be more Pythonic(try/except/finally).
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" when: foo != "some value" tags: - foo - bar
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: ...
INCLUDE + WITH EXAMPLE:- hosts: all gather_facts: false tasks: - include: foo.yml some_var={{item}} with_items: - a - b - c
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.
INTERNAL APISPlugin APIs are changing. Connection, action, and some others
will be different.
We plan on writing a transition guide for authors of plugins, tomake it easier to move them to be compatible with V2.
V2 CAN BE TESTED TODAY!$ git clone https://github.com/ansible/ansible.git$ cd ansible$ . v2/hacking/env-setup
profit!
We are targeting March 2015 for the switchover on the develbranch.
Ansible 1.9 will be released before the switchover, and will be thelast major release using the 'v1' code.
The original code will still be available in the source tree, with itsown `hacking` script available should people wish to continue
using it from checkout.
As noted above, we are aiming for a release in early-mid March.
This release will primarily be about bug fixes and new modules inthe "extras" repo, but will also introduce support forPowerBroker authentication in addition to su/sudo..
This version will also introduce the use of official releasecandidates for testing.