Open Stack

On 2021-12-01 12:46:08 -0700 (-0700), Alex Schultz wrote:
[...]
> For this reply, "LTS Distro" means support/updates > 13 months  This
> means regular Ubuntu and Fedora releases don't qualify. Ubuntu LTS,
> CentOS Stream * and Debian LTS would qualify.  Can we all agree on
> this definition?
> 
> https://ubuntu.com/about/release-cycle
> https://www.centos.org/cl-vs-cs/#end-of-life
> https://wiki.debian.org/LTS
[...]

Technically, Debian on its own would meet this definition, as
releases come every ~2.5 years and are generally supported for ~6
months after the next release, making it roughly 3 years of normal
support. "LTS" in Debian is something which extends beyond the
normal security support for the distribution, but is irrelevant here
given the already long support timeframe for Debian releases.

> Jeremy said in a subsequent message that the interpreter comes
> from an LTS distro which IMHO means the EOL is the distro's EOL
> not Python's. Now this brings up issues if we can't get 3.6 fixes
> for specific versions of our dependencies that come in via pypi,
> but do we have data how often this is actually a problem?

You can get some idea by counting the number of times
"python_version" appears in global-requirements.txt or
upper-constraints.txt in openstack/requirements by the end of a
release cycle.

> Isn't that already a problem for stable branches?

Not really, since we freeze openstack/requirements when branching,
in a crude attempt to mimic testing with versions contemporary with
what distros are probably packaging alongside that OpenStack
release.

> Or are we worrying about something that doesn't happen?  We need
> to all agree on where EOL dates come from for dependencies and
> expectations around them.

It's definitely a thing which happens. We're running Python 3.6 jobs
on OpenStack project master branches now while pinning to older
versions of more than a dozen dependencies, and when mainline 3.6
EOL comes that will almost certainly rise sharply as our
dependencies start to aggressively drop support for it. Having this
happen during a cycle definitely leads to a wider disparity in
versions of dependencies used for various jobs, compared to having
it happen after we freeze requirements for the release.

> LTS Distros are being referenced in this thread but people keep going
> back to EOL dates that are not aligned with these distros.  For the
> full OpenStack project ecosystem, testing is occurring on Ubuntu,
> CentOS, and a bit of Debian.  IMHO when a release (e.g. Yoga) is
> released, we should use what is available at the start of cycle and
> using the EOL dates of the tested distros in determining decisions
> around version support.  If we use this for Yoga, realistically CentOS
> Stream 8 and Ubuntu 20.04 could be used which would leave us with
> 3.6/3.8.  It seems Debian was the only one with 3.7
> (https://wiki.debian.org/Python). Since CentOS Stream 9 was released
> during the Yoga cycle, we couldn't pick it up as a version until Z but
> we could then make the 3.8 cutoff then.  If Ubuntu releases a new
> version (the website says they might) during Yoga with 3.9 then we
> could talk about raising it further in Z.  This would allow for lower
> bounds to be pushed, but requires that one of our qualifying LTS
> distros in check/gate were already available at the start of a cycle.

Actually, Debian's last stable release (11 a.k.a. bullseye) was
available approximately 2 months before we started on OpenStack Yoga
and uses Python 3.9 as its default python3, so testing 3.6 and 3.9
would be the preferred lower and upper bounds there.

> What I would like is that people stop pointing to Python's EOL date
> which is newer but does not actually align with the assumption of an
> LTS distro.  It would only make sense to use that date if we were
> basing our testing on non-LTS distros which may be able to follow
> their EOL dates more closely.
[...]

The underlying reason it keeps coming up is that, during
development, we don't attempt to match the versions of dependencies
we test with to the versions those distributions are packaging
alongside the Python 3 interpreter. As a result, when our
dependencies begin dropping upstream support for Python releases is
what impacts us, at least under our current testing model.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211201/b49cba8d/attachment.sig>