On 7/9/21 7:32 PM, Patrick Riehecky wrote: > I'm really torn on these ideas. > > I guess I'm trying to sort out who we'd be helping most and who we'd be > harming least with each of these ideas. > > Is there a CentOS user community of folks who apply nightly updates but > don't respond to errors during that process? yes, there is. I know of installations ( not mine :) ) which have a "yum -y update " run from cron.daily > Since we don't enable > automatic updates by default (sad face), I'm trying to figure out which > workflows would be impacted by each approach and what options are the > most transparent and predictable for each one. > > Pat > > On Thu, 2021-07-08 at 14:39 -0500, Carl George wrote: >> One idea I've been noodling on is whether or not at some point after >> the EOL we should have mirrorlist.centos.org respond to requests for 8 >> repos with 8-stream repos, which effectively converts any remaining >> CentOS Linux 8 systems to CentOS Stream 8. I see this as a natural >> extension of how CentOS has never supported (to the extent CentOS >> "supports" anything) staying on old previous minor releases of a major >> release. CentOS Stream is still CentOS. 8-stream isn't that >> different from 8. CentOS Stream 8 is the latest CentOS 8. (Note: >> These are facts that I'm not interested in arguing with people about. >> If you feel the need to reply to those particular points, don't expect >> a reply from me.) >> >> I can envision three possible scenarios. >> >> 1. Change mirrorlist to respond to 8 repo requests with 8-stream repos >> at the EOL date. This ensures that CentOS Linux 8 systems continue to >> get security updates by way of converting them to CentOS Stream 8. It >> also reinforces that CentOS Stream 8 is the latest CentOS 8. >> Obviously people who are not fans of the new project direction will >> view this negatively and lash out about Red Hat for supposedly forcing >> them to use CentOS Stream 8. >> >> 2. Same as 1, but wait some period of time after the EOL date, such as >> 1-3 months. Waiting much longer than that would result in effectively >> updating from 8.5 directly to 8.7, which is less appealing. >> >> 3. Don't change mirrorlist to respond to 8 repo requests with 8-stream >> repos, ever. This approach gives users the maximum amount of choice >> to migrate to either CentOS Stream 8, RHEL 8, or another RHEL 8 >> rebuild, when and only when they are ready. The downside is that many >> systems will be left without security updates for long periods of >> time, until users decide to take action. CentOS Linux 8 hits to EPEL >> are still growing [0], which makes me believe that many people still >> are unaware of the EOL change. >> >> [0] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_mattdm_status_1411012254812852225&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=oixumVmD1GoeJq4OZKbBufa-OWf9TUhj4cANWnM1w-I&s=GtEd9JBFEf3Xns8RX87R4HtITBOi4kKspsCkTErIxNM&e= >> >> >> On Thu, Jul 8, 2021 at 12:10 PM Rich Bowen <rbowen at redhat.com> wrote: >>> As we get closer to the CentOS Linux 8 EOL, we're getting more and >>> more >>> questions about how the EOL is actually going to work. While there >>> tends >>> to be a great deal of "everybody just knows how it works" among the >>> people actually on this list, we're getting attention from a much >>> larger >>> audience now, and they don't know. >>> >>> To that end, I want to make sure we have clear documentation, >>> prominently displayed, that sets expectations as we get closer to >>> that >>> December 31 date, >>> >>> So ... as I understand, our process is basically: >>> >>> >>> 1. Copy old data to vault.centos.org >>> 2. Update web pages and links to say it is now on vault.centos.org >>> 3. Turn off mirrorlist to that release name (aka all requests to >>> CentOS-8 will 404) >>> 4. Remove the data from the main mirrors with a file saying look at >>> vault.centos.org >>> 5. Mirrors pick all that up in 4-8 hours. >>> >>> >>> Is there more to it than this? Will we do anything different this >>> time >>> because CL8 is a special case? Am I missing any steps, or have I >>> misunderstood any of the steps? Is this already documented somewhere >>> that I simply haven't found yet? >>> >>> Are there any changes to this process that we *want* to advocate for, >>> given the special nature of this particular EOL? (No, I absolutely >>> cannot promise anything, but I can ask.) >>>