On Wed, Apr 20, 2022 at 8:55 PM Nico Kadel-Garcia <[email protected]> wrote:
>
> On Wed, Apr 20, 2022 at 9:52 AM Matt Martz <[email protected]> wrote:
> >
> > There are a number of reasons, some of which are related to the fact that
> > Py3.6 had already transitioned to only receiving security fixes by the time
> > we made the decision. We decided to jump to the most recent python version
> > still accepting general bug fixes. There are a number of features such as
> > importlib.resources, dataclasses, contextvars, changes to
> > multiprocessing/threading, PEP563, PEP538, ordered dicts. Some of those
> > align with py3.7, but since RHEL8 didn't include 3.7 and 3.7 was only
> > receiving security fixes, we jumped to 3.8. Additionally there is a cost
> > associated, both human and monetary, with supporting a larger set of
> > versions. Ultimately we made a decision to only support the 3 most recent
> > upstream Python versions from a controller code perspective. ansible-core
> > 2.14 will transition to supporting Py 3.9-3.11. Our plan for RHEL/CentOS
> > packaging is that ansible-core 2.14 will be packaged on RHEL using Py3.11;
> > You can go back and watch the Ansible contributor summit video for some
> > explanation about these plans. 2.13 will likely transition to being
> > packaged on RHEL using Python 3.9.
> These ansible-core RPMs for CentOS and RHEL 8 were published well
> after I started my .spec files. I'm glad to see them. On the other
Oh, and credit to Kevin Fenzi, I was working mostly on top of his
Fedora work. I don't want credit for someone else's work.
> hand, I'm alarmed that the SRPM has bundled tarballs of assembled
> dependencies with no provenance. Listing a version number alongside
> them is one thing, a URL that points to the source code for the
> dependencies would be better. Updating the related RPMS to match would
> be even better, though it could take more work. Almost all other
> python based RPMs publish a URL for the source code tarball, I'd like
> to strongly suggest including those for these tarballs.
Staring more closely, the tarball for ansible-core itself is labeled
as "ansible-[commit].tar.gz", and does not match the 2.12.3 tarbally
from pypi. This is non-standard for python modules, and tools, which
all come from the pypi.org URL's rather than the git-commit based
tarballs. Since the git commit based contents don't quite match the
pypi.org published tarball, I'd actually recommend using the pypi.org
tarball, since that is what is used for "pip install".
The other bundled modules are for:
python38-packaging - this is available by RHEL as a "modular"
RPM, run "dnf module enable python38-devel; dnf module enable
python38" to get these
python38-pyparsing - this is published by RHEL as a "modular" RPM,
python38-straight-plugin - this is not currentl
It also extensively uses a hard-coded "python38" rather than setting
"python3_pkgversion" and "python3_version" That makes it automatically
inconsistent and incompatible with Fedora or EPEL builds. I'd strongly
using "pyton%{python3_pkgversion} instead, and use: this at the start:
> I'll be very surprised if python 3.11 is ready for ansible-core by the
> time RHEL 8.6 is published. I suppose Dimitri could continue to
> internally bundle other tarballs if and as needed, but I went through
> that with Subversion and Samba, and it gets hairy quickly.
>
> > Note that there is also a difference between controller code and target
> > code. Module code still supports Python 2.7, Python 3.5+, and ansible-core
> > 2.11 added support for "module respawn" to allow a module to respawn itself
> > onto a more appropriate python interpreter that contains the libraries the
> > module needs. We also dropped use of the selinux python bindings in
> > ansible-core and switched to ctypes.
>
> Yes, I've noted this before. It's why the system works well even if
> the local python is.... a far-advanced python 3, and not available on
> the target system. I've noticed..
>
> > As far as RPM packaging, RHEL8.6 and 9.0 (planned release in May iirc) will
> > contain ansible-core 2.12, and all required dependencies. The AAP repo
> > contains ansible-core 2.13. CentOS Stream 8 and 9 both contain ansible-core
> > 2.12 as of now: https://git.centos.org/rpms/ansible-core/branches
>
> That's good, with the concerns about internally bundled dependencies
> that I've mentioned.
>
> Nico Kadel-Garcia
>
> > For EL7, it was explicitly decided to drop support for it as an
> > organization as a controller, so Tower (Automation Controller) and AWX
> > don't run there either, or at a minimum aren't tested there. Although I
> > guess an SCL with a newer Python could be used for in house packaging of
> > ansible-core as an RPM for EL7.
> >
> >
> >
> > On Tue, Apr 19, 2022 at 7:58 PM Nico Kadel-Garcia <[email protected]> wrote:
> >>
> >> The system python on RHEL 7 and RHEL 8 is now python 3.6, and will be
> >> for the remaining lifespan of RHEL 7 for a few years, and of RHEL 8
> >> for at least the next 8 years. It's especially hindered by the general
> >> dislike of CentOS 8 and of the multiple yum streams and of
> >> "modularity" for RHEL 8, both of which have been burdens to RHEL and
> >> CentOS users. So I anticipate RHEL 7 being in use for core servers
> >> like ansible servers, or ansible tower or awx, far longer than
> >> anticipated.
> >>
> >> Python 3.8 is available from RedHat for RHEL 8, but not for RHEL 7.
> >> The suite of modules published are incomplete: They lack critical
> >> python modules like python38-resolvelibs and python38-nose.
> >>
> >> I'm game to update my RPM building setups to support python3.8 builds
> >> for ansible, but seems likea lot of work for an individual contributor
> >> when it may be much more easily resolved, and long extend the
> >> supportable integration of a commercially supported project by
> >> encouraging Red Hat employees to support RedHat's commercial operating
> >> systems.
> >>
> >> I don't currently have an Ansible Tower license in hand, and AWX for
> >> RPM based deployment seems to have foundered. Are there no RPM's
> >> being used for a contemporary ansible-core, itself, in that commercial
> >> offering? If it's entirely reliant on doing "pip install", it will
> >> need to be "pip3.8 install" and will only work on RHEL 8 based systems
> >> for Red Hat offering for the foreseeable future. And it won't work on
> >> RHEL 7, which I anticipate many, many current users staying with
> >> rather than facing the unwelcome features of RHEL 8 based systems,
> >> such as "modularity", the multiple and sometimes overlapping yum
> >> streams, and the "CentOS Stream" fiasco.
> >>
> >> If someone's already done the work of RPM bundling ansible-core for
> >> Ansible Tower, I'd appreciate seeing the .spec files. If not, you're
> >> quite welcome to mine, which are based on Fedora work.
> >>
> >> Nico Kadel-Garcia
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Ansible Project" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to [email protected].
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/ansible-project/CAOCN9ryx0YGCUAgVbWENjuwuR2LfpHOWUx8JA_5XFDPsd8rE6w%40mail.gmail.com.
> >
> >
> >
> > --
> > Matt Martz
> > @sivel
> > sivel.net
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ansible Project" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/ansible-project/CAD8N0v_PGwe0sxZo0S4kqc5D4EJhd1QGK8WG1nSxj_s%3Do4CQ9w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAOCN9rypaQATSvVcuW01-xYyt76o84H28jg_bjr0a9boX%2Br4VA%40mail.gmail.com.
