Technology Preview of Ansible Core 2.19 in Ansible Automation Platform 2.5

Updated -

Technology Preview of Ansible Core 2.19 in Red Hat Ansible Automation Platform 2.5

As the Product Manager of Ansible Core, it is my pleasure to share an early look at the upcoming release of Ansible Core 2.19, available as a *Technology preview in Red Hat Ansible Automation Platform 2.5. This release brings security enhancements, improved performance, and tighter integration capabilities that continue to refine and expand what automation practitioners can accomplish. Let’s explore what’s new and why it matters to you.

*Technology Preview features provide early access to upcoming product innovation

What is Ansible Core?

Ansible Core is the foundational layer to Ansible Automation Platform that performs the automation derived from Ansible Playbooks.
Ansible Core runs playbooks that are orchestrated as jobs in the highly scalable enterprise platform that is Ansible Automation Platform. Ansible Core is also responsible for the Domain Specific Language that makes Ansible Playbooks human readable.

Technology Preview of Ansible Core

The importance of Ansible Core is paramount to the operational success of your automation use case, for this reason we take the release and upgrading of Ansible Core very seriously as we do not wish to impose adverse effects on your automation use cases.
For these reasons, we are leveraging tried and tested Red Hat release procedures bringing Red Hat Ansible Automation Platform customers an early preview of Ansible Core 2.19. Let’s talk about the benefits: 

  • You will have early access to test and accredit the release prior to it becoming default in a future AAP release.
  • You have time to raise issues w regarding the use of the new release in your environment for your automation use cases.
  • Allow for early skills development in new ways of doing things in the release.
  • Strategically plan for impacts to your automation use case and provide feedback.
  • Enable faster adoption of future release of AAP that ships by default the preview release of Ansible Core.

These benefits to you allow us Red Hat to develop fast and release faster by engaging directly with our customer base in a safe Technology Preview encapsulation.
Customers should join the technology preview of Ansible Core 2.19 to gain early access for testing before it becomes the default in a future AAP release. This allows time to identify and raise issues with Red Hat, develop skills with the new release, plan for impacts on automation use cases, and enable faster adoption of future AAP releases. Ultimately, it's about ensuring a smooth transition and proactively addressing potential problems.

Support Guidance for Technology Preview

We release it as Technology Preview so that customers clearly understand that the software they are testing is exactly that, it is a test scenario and should be treated as such. Technology Preview should NOT be installed in production.
If you encounter an issue with Ansible Core 2.19 you should raise a standard support ticket stating the Ansible Core version as 2.19 Technology Preview. We will look to address the issue in accordance with the technology preview support guidance https://access.redhat.com/support/offerings/techpreview
We would really appreciate any and all issues raised to support our quality goals and high standards for a generally available release

What you can expect from Ansible Core 2.19

Templating Modernization

Ansible Core 2.19 Technology Preview includes Templating Modernization which aims to improve performance, security, and maintenance.

Impact on Playbooks: All playbook authors may be affected. Some existing playbooks may need adjustments due to changes in how templates are evaluated and restrictions to prevent dangerous practices. Ansible will fail to process a playbook when it encounters a substitution it no longer understands.

Error Message Changes: While improved, some error messages may initially require understanding of the new templating behavior. We plan to add deprecation warnings to old style constructs when they are encountered for previous versions of ansible, this technology preview helps us understand where these deprecation warnings need to go. 

Testing Required: Users should thoroughly test their playbooks in a non-production environment to identify potential issues with the new templating.

Example Modification: Existing when conditions like tmp_files.files may need to be updated to when: tmp_files.files is truthy, when: tmp_files.files|length > 0, or when: tmp_files.files != [].
In summary, while these changes aim for better performance and security, they could initially require playbook adjustments and careful testing. 

Improved Error Reporting

The most user facing improvement that results from the modernization of many parts of the code base is improved error reporting.

In the common example of a missing required argument for a module, an error message would have been previously reported like the following.

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: NoneType: None
fatal: [localhost]: FAILED! => {"changed": false, "msg": "src and dest are required"}

The improved error report in Ansible Core 2.19 will now provide much more information, including the file, line number, and column of the issue, in a much friendlier format.

[ERROR]: Task failed: Action failed: src and dest are required
Origin: ~/projects/ansible/playbooks/playbook.yml:4:7

2   gather_facts: false
3   tasks:
4     - template:
        ^ column 7

fatal: [localhost]: FAILED! => {"changed": false, "msg": "src and dest are required"}

Templating errors are also much improved, and in the example of a templating issue accessing a key from a dictionary that doesn't exist would have provided an error like the following.

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ansible.errors.AnsibleUndefinedVariable: 'dict object' has no attribute 'ansible_host'
fatal: [localhost]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'ansible_host'"}

The new error message will provide an output similar to the above, but will extend it with further context outlining the cause to be in a template file.

[ERROR]: Task failed: object of type 'dict' has no attribute 'ansible_host'

Task failed.
Origin: ~/projects/ansible/playbooks/playbook.yml:4:7

2   gather_facts: false
3   tasks:
4     - template:
        ^ column 7

<<< caused by >>>

object of type 'dict' has no attribute 'ansible_host'
Origin: ~/projects/ansibledev/playbooks/tmpl.j2

fatal: [localhost]: FAILED! => {"changed": false, "msg": "Task failed: object of type 'dict' has no attribute 'ansible_host'"}

 

SSH Connection Improvements

Ansible for many use cases will connect to the target host/node using SSH, even newer Enterprise server editions of Microsoft Windows now support SSH as a connection method. We have made a number of improvements to the SSH connection capability as follows; 

  • We added support for the OpenSSH native SSH_ASKPASS functionality to replace the need for use of "sshpass", removing an extra dependency.
  • We added a pure python ssh-agent client (like what ssh-add offers). This was extended to the ssh connection plugin in a way that can handle storing keys in inventory (or any var) and supplying a passphrase as well.

Python 3.12 Support 

We’ve made early strides in enabling compatibility with Python 3.12. While official support will arrive in a future stable release, contributors and users eager to experiment with Python 3.12 can now begin testing their playbooks and collections to ensure forward compatibility. Minimum compatibility will be Python 3.11 for control Node and target nodes will need python 3.8 or higher.

Enhanced Windows Support

We have added more support for the Windows platform in the form of Windows Defender Application Control.
- Ansible will be able to sign content on the Windows Platform so Windows Defender will function and execute.*
Github Issue Link 

Deprecation(s)

With all Ansible Core releases things come and go, in Ansible Core 2.19 we are deprecating the use of the SSH connection plugin known as PARAMIKO, this is because Cryptography 48 is dropping support in TripeDES*. This aligns with Red Hat's broader strategy for support of this library in Red Hat products.
Github Issue Link

How do I participate in the Technology Preview

We will be making available an Ansible Automation Platform Execution Environment Image that contains Ansible Core 2.19 Technology Preview. 
We will make this EE available at registry.redhat.com and clearly label it as Technology Preview.

registry.redhat.io/ansible-automation-platform-tech-preview/ee-minimal-el8:2.19
registry.redhat.io/ansible-automation-platform-tech-preview/ee-minimal-el9:2.19

We stress that you should ONLY sync this image to a test Ansible Automation Platform cluster for the purpose of testing your automation use cases with this Technology Preview version of Ansible Core.
You should NOT sync this technology preview execution environment image to a Production Cluster.
If you experience issues in your test environment, you can simply change the Execution Environment image referenced in your Job Template or Organisation back to a previous version with no harm done.
Any issues that you find would be gratefully received by our support organisation through the normal support ticket process. Technology Preview support cases do not have the same SLA as your normal contract. Technology Preview support cases are best efforts and hence should not be raised in production environments.

Final Thoughts

Ansible Core 2.19 is a clear step forward in our mission to empower automation at scale, across diverse IT environments. Whether you’re managing infrastructure, applications, networks, or security workflows, this release delivers tools that make automation faster, more secure, and easier to extend.
Thank you for your continued support and participation with Red Hat Ansible.

Comments