Hi all,
We’re happy to announce that the first release candidate of Ansible 6.0.0 is
now available for testing!
Ansible 6.0.0rc1 will include ansible-core 2.13 as well as a curated set of
Ansible collections to provide a vast number of modules and plugins.
This is a major version update from Ansible 5.x which included
ansible-core 2.12 and there may be backwards incompatibilities in the core playbook language.
How to get it
Hi all,
We're happy to announce that the first release candidate of Ansible 6.0.0 is
now available for testing!
Ansible 6.0.0rc1 will include ansible-core 2.13 as well as a curated set of
Ansible collections to provide a vast number of modules and plugins.
I still think this package should simply be called
"ansible_collections", to avoid the repeated confusion and the
inconsistency between "ansible.egg-info" and the "ansible_collections"
python directory that it installs. It also still does not include
ansible-core, it lists a requirement for ansible-core 2.13.0 or later.
Perhaps that can be revisited for ansible 7. I've written about this
in the ansble-core git repo, which also has the mismatched name
"ansible" at https://github.com/ansible/ansible but contains only the
contemporary ansible-core software.
This is a major version update from Ansible 5.x which included
ansible-core 2.12 and there may be backwards incompatibilities in the core playbook language.
Is ansible 5.9 compatible with ansible-core 2.13 ? "pip3.8 install
--user ansible-core" now pulls in an updated jinja2 and sphinx to
build the current ansible-core 2.13.0 release. But apparently the
current ansible 5.9 release is not compatible with the current
ansible-core? This is a fairly predictable problem for out-of-phase
package releases.
How to get it
-------------
This pre-release is available on PyPI and can be installed with pip:
$ pip install ansible==6.0.0rc1 --user
Too bad that doesn’t work and never will on RHEL based operating
systems… The pip command on RHEL 7 is linked to python 2.7, which is
completely incompatible with ansible-core 6.0.0. There is no “pip”
command on RHEL 8 or RHEL 9. There is a “pip3” linked to pip3.6 on
RHEL 87 and RHEL 8 and that can only manage ansible 4.x because of the
ansible-core and python 3.8 or later dependencies
I’d frankly dump RHEL 7 for ansible servers at this point. If you want
a somewhat more recent ansible-core for localhost use, I’d not bother
installing ansible at all, only “ansible-core” for localhost use.
If you’re on RHEL 8, and you want to ansible 6 and its dependency
ansible-core 2.13, you need to do enable python 3.8 like this. You’re
going to need it for ansible-core 2.13.0.:
dnf module enable python38
dnf module enable python38-devel
dnf install pyton38 python38-devel python38-pip
Because of RHEL’s unwelcome and confusing decision to package python
3.8 and its python modules with dnf modularity, installing these
ansible requirements as RPM’s does require those extra dnf modularity
steps. I’ve frankly not met anyone who likes dnf modularity.
Otherwise, without the python3.8 dependencies, ansible-core 2.13.0 is
not installable.
After enabling modularity based python 3.8 and the related devel
modules on RHEL 8, you can safely use:
pip3.8 install ansible-core==2.13.0 --user
pip3.8 install ansible==6.0.0rc1 --user
Those two are linked by the current dependencies, and it’s safer and
easier to debug if they’re installed distinctly.
RHEL 9 and Fedora have a more recent python3 and pip3 by default and
don’t have the python 3.8 issue, but still require the “pip3” command.
Amazon Linux 2 has python 3.7, which makes it even more complex to
resolve
The sources for this release can be found here:
Release tarball:
https://pypi.python.org/packages/source/a/ansible/ansible-6.0.0rc1.tar.gz
Which does not, in fact, contain ansible-core at all. The associated
but quite distinct and separately installed ansible-core tarball is
at:
https://pypi.python.org/packages/source/a/ansible-core//ansible-core-2.13.0.tar.gz
Wheel package: https://files.pythonhosted.org/packages/py3/a/ansible/ansible-6.0.0rc1-py3-none-any.whl
SHA256: ad46296fbae5f2e22f0f2ee57aca5200165de93c1a3aaec86c023a2e6611a92a
If you do RPM packaging, as I have , the wheel packaging is not
particularly helpful. It’s the overwhelming size of the package, which
is still 300 MByte of local disk rather than the previous 500 MBytes
of local disk, and processing it with all he python dependencies for
what is over 100 distinct ansible community packages. The stability of
packaging that many individual modules together is questionable, since
very few are useful for most ansible servers and since they can be
more gracefully managed individually.
For RPM users, my RPM and dependency building tools are updated to
ansible-6.0.0rc1 and smoke tested at:
https://github.com/ansible/ansiblerepo/
For most of us, there is no requirement and no use for the “ansible”
package, and we should install and use the “ansible-core” package
directl, activating only the ansible community modules we need. It’s
much, much smaller this way, and much easier to update the list of
modules with individual testing. If you want to pick and choose among
the modules, I’d refer to:
https://github.com/ansible-community/ansible-build-data/blob/main/6/ansible-6.0.0rc1.deps
What’s new in Ansible 6.0.0rc1
- New command-line utility “ansible-community” is added in Ansible 6 that allows to print the version of the Ansible Community package.
$ ansible\-community \-\-version Ansible community version 6\.0\.0rc1
Potentially useful for package tracking, It might be even more useful
if it said which ansible community packages were deployed as part of
the "ansible collectio", rather than merely installed locally with the
"ansible galaxy" command.