Ansible 2.9 as "critical fixes only", however, Ansible 2.9 as the only widely available distributed release?
384 views
Skip to first unread message
Mark Mielke
Oct 27, 2021, 2:31:30 AM10/27/21
to Ansible Development
Hi all:
This Pull Request was closed due to "The 2.9 release is only accepting security fixes at this time in its lifecycle. As such, this PR does not meet the requirements to be backported to 2.9.":
However, availability of releases beyond Ansible 2.9 for regular users is limited:
- EPEL 7: ansible-2.9.25-1.el7.noarch.rpm
- EPEL 8: ansible-2.9.25-1.el8.noarch.rpm
- Fedora 34: ansible-2.9.25-1.fc34.noarch.rpm
This seems to be a conflict between what the Ansible devel believe to be user requirements, and what the users believe to be requirements. Something is getting blocked in the middle - perhaps the move to collections?
In any case, please re-review the true state of Ansible 2.9, and whether or not it should be considered "current". If Ansible 2.9 is really no longer current, is there effort being made by Ansible devel to ensure that Ansible 2.11 and later are published to users on standard channels?
I really don't want to fork Ansible 2.9 and manage my own patches. Especially for simple patches like the one I referenced.
Thanks,
Matt Martz
Oct 27, 2021, 9:51:29 AM10/27/21
to Mark Mielke, Ansible Development
The Ansible Core team is not responsible for OS packaging. The only official packaging of ansible-core for upstream lives on pypi.org. From a downstream Red Hat perspective, ansible-core 2.11 is available to Ansible Automation Platform customers.
I will note that ansible-core has been accepted into the appstream for CentOS Stream, and will also be included in RHEL 8.6 and RHEL 9.0 starting in May.
You will note that I mention the package name `ansible-core` several times here. In 2.10 the package was split into 2 parts, an `ansible-core` packaging containing the CLI tools, and a small number of plugins, and then the `ansible` package which bundles a large number of community maintained plugins.
I do see ansible-core packages for Fedora listed at https://src.fedoraproject.org/rpms/ansible-core
--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/b8f8c34f-2012-410a-9289-5f97940e1774n%40googlegroups.com.
Mark Mielke
Oct 27, 2021, 11:53:12 AM10/27/21
to Matt Martz, Ansible Development
On Wed, Oct 27, 2021 at 9:51 AM Matt Martz <ma...@sivel.net> wrote:
The Ansible Core team is not responsible for OS packaging. The only official packaging of ansible-core for upstream lives on pypi.org. From a downstream Red Hat perspective, ansible-core 2.11 is available to Ansible Automation Platform customers.
"Ansible Core team is not responsible for OS packaging" seems problematic when it disregards OS packaging as a concern. You call out that "From a downstream Red Hat perspective, ... " - but don't you work at Red Hat, and isn't this a conflict of interest to point out that a subscription product that you support is up-to-date, as an answer to whether the community releases are also up-to-date?
Further to this, isn't it also a conflict of interest that you would vote on whether Oracle Linux should be a supported OS target for Ansible 2.9, and would consider a one line feature to add support to be out-of-scope for Ansible 2.9? It's barely even a code change, as it is part of YAML configuration data, and it has been proven to be stable for months in Ansible 2.11.
I will note that ansible-core has been accepted into the appstream for CentOS Stream, and will also be included in RHEL 8.6 and RHEL 9.0 starting in May.
This is good - but, this also says that Ansible 2.9 is still the current release, and is only just being added to CentOS Stream. Upstream might be different, but downstream - people are still resistant of Ansible 2.10+, and this is why it is important to still patch Ansible 2.9 until these resistances can be overcome, and Ansible 2.11+ can be made generally available to users.
You will note that I mention the package name `ansible-core` several times here. In 2.10 the package was split into 2 parts, an `ansible-core` packaging containing the CLI tools, and a small number of plugins, and then the `ansible` package which bundles a large number of community maintained plugins.
Yes, I did notice. I particularly noticed it's absence on almost every distribution I checked, including Fedora 34:
# dnf list 'ansible-core'
Last metadata expiration check: 4:32:06 ago on Wed 27 Oct 2021 07:10:58 AM.
Error: No matching Packages to list
Last metadata expiration check: 4:32:06 ago on Wed 27 Oct 2021 07:10:58 AM.
Error: No matching Packages to list
I hoped to be wrong. I tried to find evidence of it being deployed at scale, and I found the opposite. Ansible 2.9 is current for most people today.
This is great. But, it is only great once it is delivered. Right now, it is not great at all.
Please take the above as constructive criticism. I am asking for an objective review. I am not trying to insult. Are there any other voices from the Core team on this issue, particularly ones that do not work for Red Hat? (And I also don't mean the Red Hat angle to be a slant... conflict of interest is insidious, and it affects us all... which is why it should be called out...)
Thanks!
On Wed, Oct 27, 2021 at 1:31 AM Mark Mielke <mark....@gmail.com> wrote:Hi all:This Pull Request was closed due to "The 2.9 release is only accepting security fixes at this time in its lifecycle. As such, this PR does not meet the requirements to be backported to 2.9.":However, availability of releases beyond Ansible 2.9 for regular users is limited:- EPEL 7: ansible-2.9.25-1.el7.noarch.rpm- EPEL 8: ansible-2.9.25-1.el8.noarch.rpm- Fedora 34: ansible-2.9.25-1.fc34.noarch.rpmThis seems to be a conflict between what the Ansible devel believe to be user requirements, and what the users believe to be requirements. Something is getting blocked in the middle - perhaps the move to collections?In any case, please re-review the true state of Ansible 2.9, and whether or not it should be considered "current". If Ansible 2.9 is really no longer current, is there effort being made by Ansible devel to ensure that Ansible 2.11 and later are published to users on standard channels?I really don't want to fork Ansible 2.9 and manage my own patches. Especially for simple patches like the one I referenced.Thanks,--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/b8f8c34f-2012-410a-9289-5f97940e1774n%40googlegroups.com.
--
Abhijit Menon-Sen
Oct 27, 2021, 1:20:08 PM10/27/21
to Mark Mielke, Matt Martz, Ansible Development
On Wed, Oct 27, 2021 at 9:22 PM Mark Mielke <mark....@gmail.com> wrote:
>
> Are there any other voices from the Core team on this issue, particularly ones that do not work for Red Hat? (And I also don't mean the Red Hat angle to be a slant... conflict of interest is insidious, and it affects us all... which is why it should be called out...)
Is there actually anyone on the core team who doesn't work for Red Hat
>
> Are there any other voices from the Core team on this issue, particularly ones that do not work for Red Hat? (And I also don't mean the Red Hat angle to be a slant... conflict of interest is insidious, and it affects us all... which is why it should be called out...)
any more? I know my commit privileges were removed without any
discussion last year.
-- Abhijit
Brian Coca
Oct 28, 2021, 1:23:58 PM10/28/21
to Ansible Development
The core team has mostly only released packages to pypi, the Ansible
site and a PPA, never to the downstream distributions. We stopped
adding packages to our site as they were not really used and most of
the distributions had their own packages already. It made more sense
when we were still a new project that most distros didn't know about,
much less included in their repos, that is not the case anymore.
Especially now that it is almost trivial to create your own package if
needed with existing tools, just point at pypi or github for the
sources.
I'm not sure where you get your numbers about 2.9 being the 'current'
used by most, it's not even the 'current' available in many distros:
Gentoo: ansible-base 2.11.6 (this is really ansible-core but i think
packager didn't want to deal with name changes every version)
Arch: ansilbe 4.7.0-1 (community package, which includes ansbile-core 2.11.6.)
ubuntu (20.04 focal: 2.9.6
ubuntu (21.04) hirsute: 2.10.7 (which is ansible-base)
ubuntu (21.10) impish: 2.10.7
debian bullseye: 2.10.7
freebsd 13: 2.9.23 (14 is due soon, not sure what they are using yet)
Those are just the ones I have at hand, I'm pretty sure you'll find
others with 2.9, 2.10 and 2.11 just depending on how aggressive the
distros are at updating versions and their own release schedules. As
for @sivel, he responded mostly with RH/fedora/Centos as that is what
he mostly deals with daily, I deal with the ones above, so that is
what I can respond to easily.
In the end the decision about not updating 2.9 comes to a policy,
which was created due to limited core resources, we cannot maintain X
versions forever, specially since the value of X changes depending on
who is asking, I still get requests to update 1.7 and 1.9. We also
cannot revise it any time a distro chooses to stay on a specific
version (for example,Debian was pinning a version due to licensing in
some files not passing their tests), it just does not scale.
This policy has been clearly stated and in place for many years (you
can check the versioned documentation, it is in git after all) and I'm
confident that our record would speak against any perceived bias, as
long as you are willing to examine all the facts.
----------
Brian Coca
site and a PPA, never to the downstream distributions. We stopped
adding packages to our site as they were not really used and most of
the distributions had their own packages already. It made more sense
when we were still a new project that most distros didn't know about,
much less included in their repos, that is not the case anymore.
Especially now that it is almost trivial to create your own package if
needed with existing tools, just point at pypi or github for the
sources.
I'm not sure where you get your numbers about 2.9 being the 'current'
used by most, it's not even the 'current' available in many distros:
Gentoo: ansible-base 2.11.6 (this is really ansible-core but i think
packager didn't want to deal with name changes every version)
Arch: ansilbe 4.7.0-1 (community package, which includes ansbile-core 2.11.6.)
ubuntu (20.04 focal: 2.9.6
ubuntu (21.04) hirsute: 2.10.7 (which is ansible-base)
ubuntu (21.10) impish: 2.10.7
debian bullseye: 2.10.7
freebsd 13: 2.9.23 (14 is due soon, not sure what they are using yet)
Those are just the ones I have at hand, I'm pretty sure you'll find
others with 2.9, 2.10 and 2.11 just depending on how aggressive the
distros are at updating versions and their own release schedules. As
for @sivel, he responded mostly with RH/fedora/Centos as that is what
he mostly deals with daily, I deal with the ones above, so that is
what I can respond to easily.
In the end the decision about not updating 2.9 comes to a policy,
which was created due to limited core resources, we cannot maintain X
versions forever, specially since the value of X changes depending on
who is asking, I still get requests to update 1.7 and 1.9. We also
cannot revise it any time a distro chooses to stay on a specific
version (for example,Debian was pinning a version due to licensing in
some files not passing their tests), it just does not scale.
This policy has been clearly stated and in place for many years (you
can check the versioned documentation, it is in git after all) and I'm
confident that our record would speak against any perceived bias, as
long as you are willing to examine all the facts.
----------
Brian Coca
Kevin Fenzi
Oct 28, 2021, 4:14:12 PM10/28/21
to Ansible Development
On Tue, Oct 26, 2021 at 11:31:30PM -0700, Mark Mielke wrote:
> Hi all:
Hello.
> This Pull Request was closed due to "The 2.9 release is only accepting
> security fixes at this time in its lifecycle. As such, this PR does not
> meet the requirements to be backported to 2.9.":
>
> https://github.com/ansible/ansible/pull/76146
>
> However, availability of releases beyond Ansible 2.9 for regular users is
> limited:
> - EPEL 7: ansible-2.9.25-1.el7.noarch.rpm
> <https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/a/ansible-2.9.25-1.el7.noarch.rpm>
> - EPEL 8: ansible-2.9.25-1.el8.noarch.rpm
> <https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/a/ansible-2.9.25-1.el8.noarch.rpm>
> - Fedora 34: ansible-2.9.25-1.fc34.noarch.rpm
> <https://dl.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/Packages/a/ansible-2.9.25-1.fc34.noarch.rpm>
f34 does now have ansible-core also (It was in updates-testing).
So, a bit of information from me (The Fedora/EPEL ansible maintainer).
First, feel free to file a bug ( bugzilla.redhat.com / Fedora / ansible)
and I can look at adding that PR into the next round of 2.9.x updates I
send out. We are already carrying one for Rocky Linux, so it only seems
fair to include others if asked.
As far as versions and plans for Fedora / EPEL:
* We are working on a new 'ansible' package thats all the collections
from ansible 5: https://fedoraproject.org/wiki/Changes/Ansible5
That will replace the old ansible-2.9.x package in Fedora 36 and require
ansible-core for engine.
* ansible-core is available in f34/35/36 and will soon be available in
rhel8 and rhel9. epel7 will likely stick on the last 2.9.x version for a
while until it becomes untenable. Hopefully folks will have moved their
control hosts by then.
* There's a number of ansible collections packaged up in Fedora/epel:
ansible-collection-ansible-netcommon.noarch
ansible-collection-ansible-posix.noarch
ansible-collection-ansible-utils.noarch
ansible-collection-chocolatey-chocolatey.noarch
ansible-collection-community-general.noarch
ansible-collection-community-kubernetes.noarch
ansible-collection-community-mysql.noarch
ansible-collection-containers-podman.noarch
ansible-collection-google-cloud.noarch
ansible-collection-microsoft-sql.noarch
ansible-collection-netbox-netbox.noarch
and move as folks add them. You're welcome to install ansible-core and
any collections you need from there or galaxy.
Hope that helps some.
kevin
> Hi all:
Hello.
> This Pull Request was closed due to "The 2.9 release is only accepting
> security fixes at this time in its lifecycle. As such, this PR does not
> meet the requirements to be backported to 2.9.":
>
> https://github.com/ansible/ansible/pull/76146
>
> However, availability of releases beyond Ansible 2.9 for regular users is
> limited:
> - EPEL 7: ansible-2.9.25-1.el7.noarch.rpm
> - EPEL 8: ansible-2.9.25-1.el8.noarch.rpm
> <https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/a/ansible-2.9.25-1.el8.noarch.rpm>
> - Fedora 34: ansible-2.9.25-1.fc34.noarch.rpm
> <https://dl.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/Packages/a/ansible-2.9.25-1.fc34.noarch.rpm>
f34 does now have ansible-core also (It was in updates-testing).
So, a bit of information from me (The Fedora/EPEL ansible maintainer).
First, feel free to file a bug ( bugzilla.redhat.com / Fedora / ansible)
and I can look at adding that PR into the next round of 2.9.x updates I
send out. We are already carrying one for Rocky Linux, so it only seems
fair to include others if asked.
As far as versions and plans for Fedora / EPEL:
* We are working on a new 'ansible' package thats all the collections
from ansible 5: https://fedoraproject.org/wiki/Changes/Ansible5
That will replace the old ansible-2.9.x package in Fedora 36 and require
ansible-core for engine.
* ansible-core is available in f34/35/36 and will soon be available in
rhel8 and rhel9. epel7 will likely stick on the last 2.9.x version for a
while until it becomes untenable. Hopefully folks will have moved their
control hosts by then.
* There's a number of ansible collections packaged up in Fedora/epel:
ansible-collection-ansible-netcommon.noarch
ansible-collection-ansible-posix.noarch
ansible-collection-ansible-utils.noarch
ansible-collection-chocolatey-chocolatey.noarch
ansible-collection-community-general.noarch
ansible-collection-community-kubernetes.noarch
ansible-collection-community-mysql.noarch
ansible-collection-containers-podman.noarch
ansible-collection-google-cloud.noarch
ansible-collection-microsoft-sql.noarch
ansible-collection-netbox-netbox.noarch
and move as folks add them. You're welcome to install ansible-core and
any collections you need from there or galaxy.
Hope that helps some.
kevin
Mark Mielke
Oct 28, 2021, 11:01:07 PM10/28/21
to Brian Coca, Ansible Development
On Thu, Oct 28, 2021 at 1:23 PM Brian Coca <bc...@redhat.com> wrote:
The core team has mostly only released packages to pypi, the Ansible
site and a PPA, never to the downstream distributions. We stopped
adding packages to our site as they were not really used and most of
the distributions had their own packages already. It made more sense
when we were still a new project that most distros didn't know about,
much less included in their repos, that is not the case anymore.
Especially now that it is almost trivial to create your own package if
needed with existing tools, just point at pypi or github for the
sources.
Understood re: the responsibility of packaging, pushed down to the subject matter experts with packaging concerns.
My concern relates to enabling collaboration. For me, the Ansible project represents a point of collaboration, where users share concerns, and work together. While it is normal for patches to be first introduced locally for the people with an itch to scratch, a key value of open source is the ability to contribute upstream changes, and share the overhead. So, where should this collaboration happen? Where should these patches be shared? If the "community" has patches against a release such as Ansible 2.9, where should they be posted to, such that others can also access them?
To me, for packages to be held downstream in a RPM .spec file for an extended period of time, is a small failure to collaborate. It is a papercut. But, enough deep papercuts, or many papercuts leads to bleeding.
Now, it's possible that Ansible 2.9 should die - and the packagers are being hostile. Or, perhaps a company like Red Hat might be forced to support a product long past it's normal end of life. In such a case, a company like Red Hat might be forced to set up their own test infrastructure and provide headcount to support these older releases. But, it doesn't look like we are truly there yet. I still see patches on Ansible 2.9. You still have automated tests and builds running. Everything is still set up to support Ansible 2.9 in Github. It is still a place where changes can be shared. This makes it a choice to block merges.
I'm not sure where you get your numbers about 2.9 being the 'current'
used by most, it's not even the 'current' available in many distros:
Gentoo: ansible-base 2.11.6 (this is really ansible-core but i think
packager didn't want to deal with name changes every version)
Arch: ansilbe 4.7.0-1 (community package, which includes ansbile-core 2.11.6.)
ubuntu (20.04 focal: 2.9.6
ubuntu (21.04) hirsute: 2.10.7 (which is ansible-base)
ubuntu (21.10) impish: 2.10.7
debian bullseye: 2.10.7
freebsd 13: 2.9.23 (14 is due soon, not sure what they are using yet)
It's probably just me - but most of those are not "many users" to me. A lot of older Ubuntu out there, and almost nobody I know uses Debian, FreedBSD, Arch, or Gentoo. For me, I checked the distributions that were important to me, and everything is 2.9 today.
Those are just the ones I have at hand, I'm pretty sure you'll find
others with 2.9, 2.10 and 2.11 just depending on how aggressive the
distros are at updating versions and their own release schedules. As
for @sivel, he responded mostly with RH/fedora/Centos as that is what
he mostly deals with daily, I deal with the ones above, so that is
what I can respond to easily.
Yes, but @sivel confirmed that outside of Red Hat's subscription services, 2.9 really is what is common still. He didn't use these words, but he confirmed that 2.11+ support was entering CentOS Stream, which is confirmation that it is not deployed beyond CentOS Stream.
In the end the decision about not updating 2.9 comes to a policy,
which was created due to limited core resources, we cannot maintain X
versions forever, specially since the value of X changes depending on
who is asking, I still get requests to update 1.7 and 1.9. We also
cannot revise it any time a distro chooses to stay on a specific
version (for example,Debian was pinning a version due to licensing in
some files not passing their tests), it just does not scale.
I totally agree. You shouldn't support all releases forever. But, you do support 2.9 right now. And, I took a look through the patches - and while they are small and few, they are not "security fixes only" as @sivel suggested, nor are they "critical fixes only" as I summarized. There was a choice made to include or exclude particular patches, as there should be. But, a very trivial request to ensure that Ansible 2.9 can reliably work against an Oracle Linux target machine, that has been in 2.11 for most of 2021 without apparent issue, was blocked. It's a one line change. So, let's avoid extremes here. Changes are being made to 2.9, and a very trivial change was rejected. This was a choice. It was probably less effort to merge the change, than to argue with me.
This policy has been clearly stated and in place for many years (you
can check the versioned documentation, it is in git after all) and I'm
confident that our record would speak against any perceived bias, as
long as you are willing to examine all the facts.
I looked the changes, and from my perspective - many trivial changes have been introduced over the last year. I think "allow Ansible to remotely manage Oracle Linux 8" is both a trivial change, and an important enough change to merge.
You disagree?
Mark Mielke
Oct 28, 2021, 11:22:44 PM10/28/21
to Kevin Fenzi, Ansible Development
On Thu, Oct 28, 2021 at 4:14 PM Kevin Fenzi <ke...@scrye.com> wrote:
> However, availability of releases beyond Ansible 2.9 for regular users is
> limited:
> - EPEL 7: ansible-2.9.25-1.el7.noarch.rpm
> <https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/a/ansible-2.9.25-1.el7.noarch.rpm>
> - EPEL 8: ansible-2.9.25-1.el8.noarch.rpm
> <https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/a/ansible-2.9.25-1.el8.noarch.rpm>
> - Fedora 34: ansible-2.9.25-1.fc34.noarch.rpm
> <https://dl.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/Packages/a/ansible-2.9.25-1.fc34.noarch.rpm>
f34 does now have ansible-core also (It was in updates-testing).
So, a bit of information from me (The Fedora/EPEL ansible maintainer).
Thank you very much, Kevin. Now that I know it is available, I will help with testing ansible-core. Please let me know if you need any other help.
I would much rather contribute to your work (and upstream Ansible), then maintain a local patch and selfishly rebase your work. :-)
First, feel free to file a bug ( bugzilla.redhat.com / Fedora / ansible)
and I can look at adding that PR into the next round of 2.9.x updates I
send out. We are already carrying one for Rocky Linux, so it only seems
fair to include others if asked.
I think it is a small failure for individual packagers to have to maintain their own downstream patch sets long-term in isolation to each other, sharing changes using some channel outside the Github Ansible project, rather than contributing them to the Github Ansible project and directly collaborating between packagers. However, in many cases - it is the path of least resistance.
I have opened
As far as versions and plans for Fedora / EPEL:
* We are working on a new 'ansible' package thats all the collections
from ansible 5: https://fedoraproject.org/wiki/Changes/Ansible5
That will replace the old ansible-2.9.x package in Fedora 36 and require
ansible-core for engine.
* ansible-core is available in f34/35/36 and will soon be available in
rhel8 and rhel9. epel7 will likely stick on the last 2.9.x version for a
while until it becomes untenable. Hopefully folks will have moved their
control hosts by then.
This sounds great, and the transition plan sounds smart as well. EPEL 7 and staying on Ansible 2.9.x makes sense to me as it is nearing end-of-life, and is one of the reasons why I think small patches such as supporting new targets like Oracle Linux 8, should still be permitted.
* There's a number of ansible collections packaged up in Fedora/epel:
ansible-collection-ansible-netcommon.noarch
ansible-collection-ansible-posix.noarch
ansible-collection-ansible-utils.noarch
ansible-collection-chocolatey-chocolatey.noarch
ansible-collection-community-general.noarch
ansible-collection-community-kubernetes.noarch
ansible-collection-community-mysql.noarch
ansible-collection-containers-podman.noarch
ansible-collection-google-cloud.noarch
ansible-collection-microsoft-sql.noarch
ansible-collection-netbox-netbox.noarch
and move as folks add them. You're welcome to install ansible-core and
any collections you need from there or galaxy.
Hope that helps some.
Reply all
Reply to author
Forward
0 new messages