Hi all,
We're happy to announce that the Ansible 5.6.0 package has been released !
Ansible 5.6.0 includes ansible-core 2.12 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 4.x which included
ansible-core 2.11 and there may be backwards incompatibilities in the
core playbook language.
Please see the porting guide (linked at the bottom) for details.
How to get it
Hi all,
We're happy to announce that the Ansible 5.6.0 package has been released !
Ansible 5.6.0 includes ansible-core 2.12 as well as a curated set of
Ansible collections to provide a vast number of modules and plugins.
I've updated my RPM building tools at
https://github.com/nkadel/ansiblerepo/ to version 5.6.0, and sent a
few notes to the author of the Fedora rawhide RPM for ansible to
include some of my fixes for it. Those include publishing the license
files as '%doc' , rather than locked into the package, and segregating
the other docs into a separate ansible-doc package.
I do believe I sent you a personal note about that when I saw your
name on the Fedora packages.
Getting collection updates from Ansible 5 with ansible-core 2.11.x
-----------------------------------------------------------------Ansible 5 includes ansible-core 2.12.x which has raised the minimum
python requirement to python>=3.8 and users have expressed an interest
in getting collection updates as they ship in Ansible 5 while keeping
ansible-core 2.11.x which still supports python>=2.7.
An ansible-galaxy requirements file based on the collections from
Ansible 5 has been made available for this use case:
https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml
I really wish you or the appropriate upstream maintainer could update
the documentation to stop saying this. It's just not true.
ansible-core is a dependency it is not included, and it's a very
confusing claim.
Also, ansible 5 seems to run fine using ansible-core 2.11 releases,
with these options for installation::
* pip3 install --user ansible-core # installs ansible-core with python 3.6
* pip3 install --user ansible --no-deps # ignores ansible-core
version, installs ansible 5.6.0
It's similar to what my RPM .spec files do, though they're more
thorough about using RPM dependency management for ansible-core and
ansible. They're also more thorough about replacing:
#!/ur/binpython
or
#!/usr/bin/env python
with:
#!/usr/bin/python3
Hi Nico,
I really wish you would stop repeating this procedure on every Ansible
release. If you want things to actually change, start a proper
discussion in the appropriate place
(https://github.com/ansible-community/community-topics/).
> Getting collection updates from Ansible 5 with ansible-core 2.11.x
> -----------------------------------------------------------------
>
> Ansible 5 includes ansible-core 2.12.x which has raised the minimum
> python requirement to python>=3.8 and users have expressed an
> interest in getting collection updates as they ship in Ansible 5
> while keeping ansible-core 2.11.x which still supports python>=2.7.
> An ansible-galaxy requirements file based on the collections from
> Ansible 5 has been made available for this use case:
> https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yamlI really wish you or the appropriate upstream maintainer could update
the documentation to stop saying this. It's just not true.
You have to distinguish between the PyPi package called `ansible`, and
the product/distribution called Ansible.
The *product/distribution* Ansible consists of both `ansible` and the
`ansible-core` PyPi packages. The *docsite*
(https://docs.ansible.com/ansible/latest/) describes both. The
*changelog* describes both. The *porting guide* also describes both.
That is why our announcement is written as it is. We are talking about
the product/distribution.
The PyPi package `ansible` does indeed depend on `ansible-core` and
does not contain it. But that it is split up into two PyPi packages is
an **implementation detail** to Ansible users. If they install Ansible
by installing the PyPi package `ansible`, they shouldn't (and don't
want to) care how exactly the ansible/ansible-playbook/ansible-doc/...
binaries and the collections included in Ansible land on their disk.
They just want them there to use them, and they want to look at the
docsite to find an accurate description on how they work.
Also, ansible 5 seems to run fine using ansible-core 2.11 releases,
with these options for installation::
I don't think anybody claims it does not. But the resulting thing is
**not** Ansible of the correct version, but simply a set of collections
with the versions as in the PyPi ansible package combined with another
ansible-core version. It is **not** what is documented on the docsite,
and is **not** what is documented in the changelog and porting guide.
For example, it does contain the wrong content for the ansible.builtin
collection, and some features that are provided to collections through
shared functionality in ansible-core (doc fragments, module utils,
plugin base classes) will not be available since you use the wrong
version of ansible-core.
A very concrete example are new suboptions for the `keyed_groups` option
that many inventory plugins offer, for example the
community.general.linode inventory plugin:
https://docs.ansible.com/ansible/5/collections/community/general/linode_inventory.html#parameter-keyed_groups
You only have these new options as documented on the Ansible 5 docsite
when you also have ansible-core 2.12 installed. With ansible-core 2.11
you cannot use `default_value` and `trailing_separator`. So if you
combine the collections from the `ansible` PyPi version 5 package with
ansible-core 2.11, you do get something else than Ansible 5.
It's similar to what my RPM .spec files do, though they're more
thorough about using RPM dependency management for ansible-core and
ansible. They're also more thorough about replacing:
If you are replacing shebangs in the Ansible modules contained in the
ansible PyPi package: there is zero need to do that. These files are
loaded by ansible-core and the shebang is replaced with the correct
shebang for the system the module is executed on. It is simply a
placeholder.
Thanks,
Felix Fontein
I really wish you would stop repeating this procedure on every Ansible
release. If you want things to actually change, start a proper
discussion in the appropriate place
(https://github.com/ansible-community/community-topics/).
This topic came up here and is IMHO relevant for normal Ansible users. So please don't try to push it away from the users.
Getting collection updates from Ansible 5 with ansible-core 2.11.x
-----------------------------------------------------------------Ansible 5 includes ansible-core 2.12.x which has raised the minimum
python requirement to python>=3.8 and users have expressed an
interest in getting collection updates as they ship in Ansible 5
while keeping ansible-core 2.11.x which still supports python>=2.7.
An ansible-galaxy requirements file based on the collections from
Ansible 5 has been made available for this use case:
https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yamlI really wish you or the appropriate upstream maintainer could update
the documentation to stop saying this. It's just not true.You have to distinguish between the PyPi package called `ansible`, and
the product/distribution called Ansible.
Understood, but...
The *product/distribution* Ansible consists of both `ansible` and the
`ansible-core` PyPi packages. The *docsite*
(https://docs.ansible.com/ansible/latest/) describes both. The
*changelog* describes both. The *porting guide* also describes both.
That is why our announcement is written as it is. We are talking about
the product/distribution.The PyPi package `ansible` does indeed depend on `ansible-core` and
does not contain it. But that it is split up into two PyPi packages is
an **implementation detail** to Ansible users.
...I have to agree with Nico that the wording and the versioning also confused me in the beginning.
Ansible users like me are interested to know whether they should update or not, especially in the case of security fixes.
Doing pip upgrade on PyPI package 'ansible' is easy because it might have a dependency on a newer version of 'ansible-core' which gets pulled in automatically. That's fine.
But if there's an important security fix only in ansible-core Ansible users have to be aware to explicitly invoke
pip install --upgrade ansible-core
to get the updates. So this "implementation detail" is indeed quite relevant to Ansible users who want to properly maintain their controller.
Ciao, Michael.
Hi Michael,
> I really wish you would stop repeating this procedure on every
> Ansible release. If you want things to actually change, start a
> proper discussion in the appropriate place
> (https://github.com/ansible-community/community-topics/).This topic came up here and is IMHO relevant for normal Ansible
users. So please don't try to push it away from the users.
I'm not saying this cannot / should not be discussed here. I'm mainly
saying that 'official' decisions on what happens to the Ansible package
are made by discussions and votes in that repository. So discussing
that here is on thing, but if you really want to change it (and Nico
seems determined), it would be better to (also) start a discussion
there.
> The *product/distribution* Ansible consists of both `ansible` and
> the `ansible-core` PyPi packages. The *docsite*
> (https://docs.ansible.com/ansible/latest/) describes both. The
> *changelog* describes both. The *porting guide* also describes both.
> That is why our announcement is written as it is. We are talking
> about the product/distribution.
>
> The PyPi package `ansible` does indeed depend on `ansible-core` and
> does not contain it. But that it is split up into two PyPi packages
> is an **implementation detail** to Ansible users....I have to agree with Nico that the wording and the versioning also
confused me in the beginning.Ansible users like me are interested to know whether they should
update or not, especially in the case of security fixes.Doing pip upgrade on PyPI package 'ansible' is easy because it might
have a dependency on a newer version of 'ansible-core' which gets
pulled in automatically. That's fine.But if there's an important security fix only in ansible-core Ansible
users have to be aware to explicitly invokepip install --upgrade ansible-core
to get the updates. So this "implementation detail" is indeed quite
relevant to Ansible users who want to properly maintain their
controller.
That's indeed a problem (especially since `pip install --upgrade
ansible` will not upgrade dependencies when `ansible` is already at the
latest version). One way to (partially) fix this would be to make sure
that Ansible is always released at most a day after ansible-core has
been released. Right now, the delay can be up to two weeks, which is
definitely too long.
Also I don't mind to update the release template by adding more
information on how ansible-core is 'contained' in ansible. I'm mainly
against completely rewriting it with different language which is more
technically correct, but less helpful and doesn't work together with
the other things (changelog, porting guide, docsite).
Cheers,
Felix
I guess that Ansible users are normally system admins I'd expect to be used to dealing with multiple packages with interdependent version numbers. So technically correct language is probably the most useful form for this audience.
Ciao, Michael.
Hi Michael,
> > I really wish you would stop repeating this procedure on every
> > Ansible release. If you want things to actually change, start a
> > proper discussion in the appropriate place
> > (https://github.com/ansible-community/community-topics/).
>
> This topic came up here and is IMHO relevant for normal Ansible
> users. So please don't try to push it away from the users.I'm not saying this cannot / should not be discussed here. I'm mainly
saying that 'official' decisions on what happens to the Ansible package
are made by discussions and votes in that repository. So discussing
that here is on thing, but if you really want to change it (and Nico
seems determined), it would be better to (also) start a discussion
there.
I've brought it up before at https://github.com/ansible/ansible/ . Oh,
wait! That's not ansible! That's ansible-core!
This software split is confusing and means different things to
different people. If "ansible" is meant to be both the curated set of
ansible collection modules, and ansible-core, bundle ansible
collections separately, as the vastly oversized bundle it is, and set
"ansible" to pull in that distinctly from ansible-core. The renaming
of the "ansible" package to ansible-core and its substitution in the
pypi.org package with a tarball which actually installs only
ansible_collection has led to a great deal of confusion, at the
expense of admins who need laborious explanations of why every
pypi.org bundle for ansible is misnamed and does not match it's
installation locaiton.
> But if there's an important security fix only in ansible-core Ansible
> users have to be aware to explicitly invoke
> pip install --upgrade ansible-core
>
> to get the updates. So this "implementation detail" is indeed quite
> relevant to Ansible users who want to properly maintain their
> controller.That's indeed a problem (especially since `pip install --upgrade
ansible` will not upgrade dependencies when `ansible` is already at the
latest version). One way to (partially) fix this would be to make sure
that Ansible is always released at most a day after ansible-core has
been released. Right now, the delay can be up to two weeks, which is
definitely too long.
That is a procedural burden, and an unwelcome one. If "ansible" means
both, make it explicitly require both as distinct packages.
I'd offer patches to bundle it with the distinct name, but I admit
that I find the array of uncommon tools used to create this tarball
obscure to tune. It's pretty trivial, but ugly, to take the ansible
tarball and tweak it into being an ansible_collections compatible
tarball and installable python module instead.
Also I don't mind to update the release template by adding more
information on how ansible-core is 'contained' in ansible. I'm mainly
against completely rewriting it with different language which is more
technically correct, but less helpful and doesn't work together with
the other things (changelog, porting guide, docsite).Cheers,
Felix
Technical language that lies outright is always confusing and
engenders mistrust of its authors. This one, I'm afraid is a fib
except in some very strange and underdocumented model where "ansible"
is an umbrella term for a suite of software packages, one of which is
actually called "ansible" over at pypi.org, and the other of which
used to be called "ansible" and is still called "ansible" over at
github. It's an unwelcome source of confusion for folks with more
productive work to do. Segregating it more carefully will ease the
path for people who don't need the very large "ansible_collections"
suite at all, and need only the much smaller and leaner ansible-core.
That may not fit the agglomerated suite of software model, but it's a
lot smaller and a lot more supportable. Isn't destabilizing
agglomeration exactly what triggered the split-off of ansible-core and
the ansible_collections in the first place? It's difficult to be sure
because I can't find a transcript or correspondence history of the
decision to split these.