<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 7/9/21 11:44 PM, Patrick Riehecky
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap="">On Fri, 2021-07-09 at 23:14 +0300, Manuel Wolfshant wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 7/9/21 7:32 PM, Patrick Riehecky wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
yes, there is. I know of installations ( not mine :) ) which have a
"yum -y update " run from cron.daily
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I guess it is a workflow issue,</pre>
</blockquote>
<p>Yes, it is.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap=""> but most of my hosts apply updates nightly and when they fail to apply I (or another team member) look into why.</pre>
</blockquote>
<br>
<p> Because you are part of an organization with proper
infrastructure, procedures and qualified people.</p>
<p> 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.<br>
</p>
<p> Not to mention the more interesting aspects generated by
botched updates ( see <span id="summary_container"><span
id="short_desc_nonedit_display">RHSA-2020:3216 ) which might
lead to </span></span><span id="summary_container"><span
id="short_desc_nonedit_display">d) the systems hung so no way
to read the mails anyway.</span></span></p>
<br>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap="">
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...</pre>
</blockquote>
<p>_THAT_ is a very good question. I will not hold my breath waiting
for a convenient answer.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap="">
"Set it and forget it" nodes that aren't "managed" by anyone are always
a problem. </pre>
</blockquote>
<p><br>
</p>
<p>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 ).<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap=""> But are those folks likely to blame us for issues</pre>
</blockquote>
<p>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"</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap=""> vs folks with managed systems who are "reading" the error reports from dnf-
automatic (etc) and aren't aware of Stream8?</pre>
</blockquote>
<p>The Universe is large and it has many aspects :)</p>
<p><br>
</p>
<p>
</p>
<blockquote type="cite"
cite="mid:98a7ec355362418753adf0012cbe25dee85ea071.camel@fnal.gov">
<pre class="moz-quote-pre" wrap="">I guess I'm not sure upgrading folks to Stream8 is in the 'predictable' end of life workflow.
</pre>
</blockquote>
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"<br>
<p><br>
</p>
<p>(*) I know, they should use an embedded router and externalize
all IT, maybe host everything in cloud. Reread the "no IT budget"
part.</p>
<p><br>
</p>
</body>
</html>