On Wed, Jun 5, 2024 at 4:41 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote: > > On Wed, Jun 5, 2024 at 3:29 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: > > > > On Tue, May 28, 2024 at 11:30 AM Casey Bodley <cbodley@xxxxxxxxxx> wrote: > > > > > > from https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/ > > > > > > all ceph builds for centos 8 will start failing then, because dnf > > > won't be able to find the centos package repos any more > > > > > > the teuthology suites for main and squid don't rely on centos 8 > > > packages any more, but cephadm suites still use the centos 8-based > > > container. these suites will break until we switch to the centos > > > 9-based images. this should happen very soon, if it hasn't already > > > > > > the quincy and reef qa suites still depend on centos 8 for packages > > > and containers, though we do build centos 9 packages for both. we'll > > > just need to backport a lot of the changes (like > > > https://github.com/ceph/ceph/pull/53517 and > > > https://github.com/ceph/ceph/pull/53901) that removed centos 8 testing > > > on main > > > > > > we've been planning to switch to centos 9-based containers for main > > > and squid, and most of the work there is done. but this will also > > > necessitate a switch for the quincy and reef releases because ceph > > > containers need security updates > > > > > > the centos 9 builds for quincy and reef are already trying to build > > > containers, but that containerization step has been failing for quincy > > > with what looks like a ganesha-related issue (see > > > https://tracker.ceph.com/issues/66253) > > > > https://github.com/ceph/ceph-build/pull/2235#issuecomment-2150782468 > > > > This is insane. They've actually turned off the mirrors and painted > > this as a "helpful" exercise in disaster recovery? Wow. > > it's important that users know when their distro stops getting > security updates. archiving the package repo seems like a reasonable > way to alert users (like us) that aren't paying attention to eol > dates. that noticeably breaks things, but has a workaround to reenable > the archived packages. if absolutely necessary, we could probably > revive c8 builds and test suites using vault.centos.org. but shouldn't > we just stop using it? It's fine for users to be strongly encouraged to migrate but we have automated tests for supported releases that depend on those distributions still functioning for build purposes. To pull the rug out from under every developer like this is simply unacceptable. I have zero interest in going back to every supported release to rearchitect support for the latest and greatest centos stream. Even worse, the workloads we run which are built against that release will probably need either upgraded too, dependencies found/updated, or any other number of "fun" things that need changed when we switch distributions. Beyond the main branch upgrade suite (especially fs:upgrade) being crippled by this change, I expect all of the upgrade suites for quincy/reef to be in a similar or worse state. We won't be able to install octopus/pacific on centos8 and then upgrade to quincy/reef. > > Are we going to have to play this game every time Centos EOLs a > > release? If so, I propose we switch to another distribution that is > > not a guinea pig environment for a downstream distro. Either switch to > > actual RHEL or a centos fork? > > > > I'm not at all amused by this waste of developers' time. > > i understand the frustration, but pretty much any distro choice will > require some level of maintenance on our part. i'm not against moving > away from centos, but that's going to cost developer time too. and > we'll still have to keep building and testing centos 9 packages for > the releases that already support it Well, let's officially start looking or developing plans for local mirrors so we can deploy those distributions even if the upstream mirrors are turned off. (To be clear, I am very appreciative of your efforts Casey in trying to prepare for this. I didn't understand how bad things would get until now.) -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
