Core Engine and Windows Updates in Ansible 2.3

May 8, 2017 by Dylan Silva

Ansible 2.3 Updates

Although the majority of the features added to Ansible 2.3 were networking related, that’s not all folks!

There were several significant changes around module management, the Core engine, and Microsoft Windows support we’d love to show off.

For full details on the release, check out the changelog here.

Module Management

In prior releases, Ansible was organized in two separate module repositories: Ansible-modules-core and Ansible-modules-extras.

The intent was to differentiate the repositories in terms of code quality, feature enablement, and supportability of the modules. We believe we’ve developed a better process.

At the launch of 2.3, Ansible has moved to a metadata-based system for modules. Ansible modules now include an ANSIBLE_METADATA Block which specifies a support category: Core, Curated or Community.

  • Core - supported and maintained by the Ansible engineering team
  • Curated - supported and maintained by the Ansible engineering team and Ansible by Red Hat partners
  • Community - supported and maintained by the Ansible community

In the new system, modules will be following a specific process per category.

Core modules

Modules that the Ansible engineering team directly maintain, and will ship with Ansible. These modules also receive slightly higher priority for pull requests. Any issues that are opened against these modules will be addressed by maintainers. Pull requests made against these modules will still have a right of first refusal if the PR does not match with the intent of the module.

Curated modules

Submitted by other companies or maintained by the community. Maintainers of these types of modules will watch for any issues reported or pull requests raised against the module. We’ll have agreements in place to ensure that pull requests are handled in appropriate ways and timeframes. In some cases, when we have access to hardware or software environments, and knowledgeable staff, the Ansible engineering team may assist in the support of these modules.

Core Maintainers

Review all modules that are classified as Curated. All proposed changes to existing Curated modules once the community maintainers of the module have approved the changes will be reviewed and accepted by the Core team as a final step. Core committers will also ensure that any issues that arise due to Ansible engine changes will be remediated. Also, it is strongly recommended (but not presently required) for these types of modules to have unit tests.

Community modules are not directly or necessarily supported by Core committers or by companies/partners associated to the module. They are maintained by the community.

The response rate to issues is purely up to the community against these types of modules.. Our engineering team will provide best effort support, but have less priority for any problem resolution.

More detail around module support can be found here.

Ansible Core Engine

Module developers are now able to include their module_utils alongside the module in site-specific directories such as ``lib``; as well as have them shipped with roles. We encourage developers to place shared code for groups of modules to be in module_utils. Making this change further extends the simplicity of using Ansible as a Playbook author as well as module developer.

Blocks can now have a name field, to aid in Playbook readability.

  - block:
    - name: Do some package updates
      - yum: name={{item}} state=installed
          - httpd
          - memcached

      - template: src=templates/src.j2 dest=/etc/foo.conf

      - service: name=bar state=started enabled=True

    when: ansible_distribution == 'CentOS'
    become: true
    become_user: root

A default strategy is configurable in ansible.cfg file. For most users, the “linear” default strategy is sufficient. However, some may want to have “free” or “serial” as their default. Now they can!

Windows Updates

Windows continued to get a lot of engineering love in Ansible 2.3.

We’ve added in (experimental) support for “runas” in the become_user method, to execute modules and scripts as a different user. The WinRM connection plugin now leverages pipelining for module execution. This has made smaller tasks significantly faster in execution. Kerberos tickets can now be managed automatically when specified. Windows modules have been refactored and standardized, adding in check-mode and diff support. Finally, how about some windows_domain management with the new modules included in this release? See the documentation on those in the links below.




Storage Modules

The desire to automate “all the things” has arisen in the world of storage!

With the Ansible 2.3 release, we now have modules that manage Infinidat Infinibox devices, as well as NetApp E-Series and Solidfire. These modules were developed by our partners. For a full list of the storage modules, please check them out here.

Tower Modules

A lot of Tower users have asked for the ability to automate functions in Tower within a playbook. Our friends in Tower engineering have created a slew of modules as a result! Here’s a quick overview of some of these modules. In short, you can now manage Tower with Ansible.

Job Management

 tower_job_launch - Giving users the ability to remotely execute existing jobs in Tower

- name: Launch a job
    job_template: "My Job Template"
    register: job

tower_job_wait - Of course all jobs may not be complete at ludicrous speeds, so having a wait function is a must

- name: Wait for job max 120s
    timeout: 120

Inventory Management

tower_group - Crud operations for groups in Tower inventory

- name: Add tower group
    name: localhost
    description: "Local Host Group"
    inventory: "Local Inventory"
    state: present
    tower_config_file: "~/tower_cli.cfg"

tower_host - Crud operations for hosts in Tower inventory

- name: Add tower host

- name: Add tower host
    name: localhost
    description: "Local Host Group"
    inventory: "Local Inventory"
    state: present
    tower_config_file: "~/tower_cli.cfg"

Send Us Your Feedback

We hope you enjoy these unique features in Ansible 2.3.

As always, we’re excited to receive feedback on this release. Please join us on Freenode IRC in #ansible or drop a message to the Ansible Mailing List. We look forward to hearing from you! When you’re done providing your feedback, take a peek at some of the sweet updates coming in Core 2.4 over here.





Dylan Silva

Dylan is a Principal Product Manager, Ansible, Red Hat. Starting as an early Core community member in Ansible's early days, Dylan now manages product roadmap for Ansible Core. He’s a self-proclaimed Linux and OSS diehard, Internet geek, and father to #Ansipup Honey. You can follow him on twitter and GitHub at @Thaumos.

rss-icon  RSS Feed