[CentOS-devel] Documenting the CentOS Linux 8 EOL process

On 7/9/21 11:44 PM, Patrick Riehecky wrote:
> On Fri, 2021-07-09 at 23:14 +0300, Manuel Wolfshant wrote:
>> 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
> I guess it is a workflow issue,

Yes, it is.


>   but most of my hosts apply updates nightly and when they fail to apply I (or another team member) look into why.

     Because you are part of an organization with proper infrastructure, 
procedures and qualified people.

     Now think about a small shop with 1-2-3 systems, no IT budget and 
no qualified personnel (*). They got help initially and 
installed/configured the machines. Knowing that they have no admin or 
external contractor, the person that did the installation tried to help 
and left the machines in a state which more or less keeps them updated 
automatically ( it's good to stay updated, right ? ). Maybe the failures 
are even mailed to someone.. but that someone does not read the mails 
because a) (s)he has actual but completely different work to do as 
$DAYTASKS, b) there were never important automatic mails so reading 
those is a pure loss of time  c) does not even understand what (s)he 
reads in those mails.

     Not to mention the more interesting aspects generated by botched 
updates ( see RHSA-2020:3216 ) which might lead to d) the systems hung 
so no way to read the mails anyway.



>
> To my mind this is compounded by AppStream/Modularity where some of
> your streams may make some of your updates fail in new/interesting
> ways.
>
> I guess I'm wondering how far off the Best Practices we want to support
> in Jan 2022...

_THAT_ is a very good question. I will not hold my breath waiting for a 
convenient answer.


>
> "Set it and forget it" nodes that aren't "managed" by anyone are always
> a problem.


Yes, they are. You are 1000 % right here. But yet they exist and leaving 
them behind because "we do not care" is neither polite nor indicated ( 
from my point of view ).


>   But are those folks likely to blame us for issues

Again, yes, they are. " RH did it again, it worked yesterday but last 
night it suddenly stopped working. And when I looked, guess what ? It 
was not the OS I installed !!!!!11111"


>   vs folks with managed systems who are "reading" the error reports from dnf-
> automatic (etc) and aren't aware of Stream8?

The Universe is large and it has many aspects :)


> I guess I'm not sure upgrading folks to Stream8 is in the 'predictable' end of life workflow.
>
from my point of view , it is not. I cannot speak for CS8 but in C6 and 
C7 I had ( rare ) issues when proprietary apps stopped working after 
upgrading a lib or another. Or the kernel ( see Cisco's vpnclient whose 
kernel module could no longer be compiled after a certain update of the 
kernel ). I live in the world of EDA tools for VLSI development and 
support for said tools is already problematic when running on more 
"classic" OSes . A moving target like CS8 is not even envisioned. I 
asked a developer from Synopsys a few years ago "Why do you always 
support your application only on OSes which are at least 2 minor 
releases behind the current one ?". His answer ? "We wait 6 months for 
the release to stabilize and we need another 6 months for internal testing"


(*) I know, they should use an embedded router and externalize all IT, 
maybe host everything in cloud. Reread the "no IT budget" part.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210710/eeb1bbf1/attachment.html>