CentOS 9 came out ... ~~ 1.5 years ago? Arguably borderline for being considered obsolete. I'm not suggesting indefinitely, but I think we're sometimes too aggressive given corporate realities.

On Sep 13, 2023, at 13:13, Casey Bodley <cbodley@redhat.com> wrote:

thanks Anthony,

users have had the opportunity to upgrade both during quincy and reef, so this isn't forcing an instant decision. if you're concerned about the future of centos, you can either stay on Reef or use our container images or deb packages for S

i don't think it's reasonable to expect the Ceph project to maintain support for centos 8 indefinitely. long-term support has always been the distro's responsibility

On Wed, Sep 13, 2023 at 11:32 AM Anthony D'Atri <anthony.datri@gmail.com> wrote:

...

Too aggressive IMHO. Corporate deployments can't rev their OS instantly and lots of people have delayed going to 9 pending shakeout of the RH vs Rocky situation.

...

On Sep 13, 2023, at 10:02, Casey Bodley <cbodley@redhat.com> wrote:

now that Reef gives our users an upgrade path away from centos stream 8 and ubuntu 20.04, i propose that we drop support for those old distros from the S release. if there's agreement here, we can stop building/testing them on main asap _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

...

CentOS 9 came out ... ~~ 1.5 years ago? Arguably borderline for being considered obsolete.

I'm not suggesting indefinitely, but I think we're sometimes too aggressive given corporate realities.

CentOS 9 will be still supported FWICT, the original mail talks about CentOS Stream 8, which was released about 4 years ago and goes EOL on May 31, 2024, which is not long after Ceph S will be even released as stable the first time, possibly even before that if S gets a bit delayed like reef did..

I have no skin in the Ceph on CentOS game, but IMO it doesn't seem aggressive to stop support for a distribution in a release if the distribution is going EOL around the time of when said release is actually done. I mean, I wouldn't expect that Debian Bullseye still gets support for Ceph S, it's main support will be EOL in ~ July 2024 too. But maybe not the best comparison as major upgrades between Debian releases are relatively easy and work since decades, so it's not as big of an issue there for corporate users.

I am a bit confused, I think I missed some news. "Ceph S"? Is that a new stream version or so? Ceph is currently still developed on rhel9 not? Or is this switching to a stream version? For my upgrade path I would like to chose the distribution closest to the development/testing environment.

...

...

CentOS 9 will be still supported FWICT, the original mail talks about CentOS Stream 8

Let's remember that good ol' plain CentOS 8 still exists and likely has more users than Stream FWIW.

...

...

which was released about 4 years ago and goes EOL on May 31, 2024, which is not long after Ceph S will be even released as stable the first time, possibly even before that if S gets a bit delayed like reef did..

I have no skin in the Ceph on CentOS game, but IMO it doesn't seem aggressive to stop support for a distribution in a release if the distribution is going EOL around the time of when said release is actually done.

I hadn't accounted for that offset in my prior reply. If Squid releases most of a year from now (has the cadence relative to Reef actual vs target been decided?) then I grudgingly concede that's long enough. OS sunsetting is more problematic when the dropped release is such that one can't feasibly update it in-situ, but one can update from Rocky/CentOS 8 ->9 without reimaging and without a change of init system.

No, S is just the next letter after R (for Reef) in the Alphabet, and means the next major release (i.e. 19.2) planned for 2024. S is used as short form of the actual codename, not sure if already definitive but it seems "Squid" was the most popular: https://pad.ceph.com/p/s

Squid for S was kind of inevitable.

On Thursday, September 14, 2023 11:33:21 AM EDT Dan van der Ster wrote:

Hi Casey,

I guess this doesn't matter for cephadm users anyway.

The cephadm "binary" is limited to supporting the lowest common python version available on all the supported platforms. It runs outside of a container context. So currently the binary is limited in what python stdlib modules and languages features. I'd personally be interested in being able to use python versions newer than Python 3.6. The current refactoring project and the "compiled" cephadm make are on track to make it supporting older Python a little less burdensome as we'll be able to eventually use a small curated set of non-stdlib dependencies. But there are good language level improvements (newer type hinting syntax comes to mind) that I'd personally like to use.

I don't think we track it via the telemetry, but it would be nice to know how many users are cephadm vs packages.

Yes please :-)

BTW, is the container image already based on steam 9 for Reef and Squid?

I just double checked main branch CI images - they're based on Centos 8 Stream. I'm pretty sure, but didn't verify, that reef images are too.

Cheers, Dan

-- Dan van der Ster CTO

Clyso GmbH p: +49 89 215252722 | a: Vancouver, Canada w: https://clyso.com | e: dan.vanderster@clyso.com

We are hiring: https://www.clyso.com/jobs/

On Wed, Sep 13, 2023 at 7:03 AM Casey Bodley <cbodley@redhat.com> wrote:

...

now that Reef gives our users an upgrade path away from centos stream 8 and ubuntu 20.04, i propose that we drop support for those old distros from the S release. if there's agreement here, we can stop building/testing them on main asap _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

On 14-09-2023 17:33, Dan van der Ster wrote:

Hi Casey,

I guess this doesn't matter for cephadm users anyway. I don't think we track it via the telemetry, but it would be nice to know how many users are cephadm vs packages.

+1

BTW, is the container image already based on steam 9 for Reef and Squid?

For Reef it is CentOS 8 stream. Squid should make the jump to CentOS 9 stream. Gr. Stefan

I think new development needs to be able to advance at at least the speed of evolution of c++ and the shipping compiler and toolchain implementations in modern Linux distributions. How the project deals with retiring old stable releases is orthogonal, but I think Casey's position seems reasonable. Matt On Thu, Sep 14, 2023 at 12:06 PM Mark Nelson <mark.a.nelson@gmail.com> wrote:

We'll need to update the performance lab nodes (they are on Centos8 stream still), but that's not the end of the world. Honestly I was planning on doing it anyway sooner or later.

I do have some concerns similar to Anthony. I know users who are still running CentOS 7 in production and are just struggling to get off that. We're pretty aggressive regarding needing Compiler/OS upgrades versus a lot of projects out there and at times it feels somewhat unnecessary.

I guess my take is that there's a balancing act here. If supporting older distros is a major burden and blocker for future growth it makes sense to drop them. If we're dropping them because we want to chase brand new C++ language features that are exciting and fun but not fundamental for the project, that's less of a justification imho.

Mark

On 9/13/23 09:02, Casey Bodley wrote:

...

now that Reef gives our users an upgrade path away from centos stream 8 and ubuntu 20.04, i propose that we drop support for those old distros from the S release. if there's agreement here, we can stop building/testing them on main asap _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

---

Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

-- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309

This. When charting a path from Ubuntu Trusty / Luminous to Bionic / Nautilus ISTR having to plan an intermediate step using Ubuntu-bundled packages, which was not ideal. Enterprises like to let new major releases of anything soak before rollout * , and qualification / infrastructure readiness take time and contend with other tasks that are seen as more mission-critical from an if-it-ain’t-broke perspective. The use of containers to factor out dependencies is valid, but not universally an option. * “Never install any even-numbered release of anything”

When using packages I like to have the opportunity to change either the OS version, or the Ceph version, but not both at the same time.