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.
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.
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.
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.
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.
tasks: - block: - name: Do some package updates - yum: name= state=installed with_items: - 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 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.
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.
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.
tower_job_launch - Giving users the ability to remotely execute existing jobs in Tower
tasks: - name: Launch a job tower_job_launch: 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
tasks: - name: Wait for job max 120s tower_job_wait: job_id: job.id timeout: 120
tower_group - Crud operations for groups in Tower inventory
tasks: - name: Add tower group 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
tasks: - name: Add tower host 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.