CentOS - May 2016 - Upgrade path from CentOS 7 to future versions

Warren Young wrote:
> On May 10, 2016, at 4:12 PM, Valeri Galtsev <galtsev at
kicp.uchicago.edu>
> wrote:
>> On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
>>> On 2016-05-10, Valeri Galtsev
>>> <galtsev at kicp.uchicago.edu> wrote:
>>>>
<snip>
>> Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas
>> RHEL (hence CentOS) is what, 10 years?
<snip>
> And in fact, more than two.  This isn?t just about RHEL vs Debian and
> derivatives of same.  Several major non-Linux OSes also manage to do
> automatic upgrades between major releases: Windows, OS X, FreeBSD...
I was under the impression that all the releases of OS X were more like
what we call subreleases (6.6->6.7). But I don't know, and don't
really
care - I don't do WinDoze, I don't do (or like) Macs.
<snip>
> Your point about the 10 year support cycle for RHEL is also invalid.  The
> time spacing between major releases is only about every 3 years, and that
> is the period that matters here.
No, it's not invalid, nor is it what matters. For example, here at work,
we have clusters, and a small supercomputer, all running 6.x (in the case
of the supercomputer, it's an SGI-modified RHEL 6.x), and they'll go to
7
probably when they're surplused replaced.

Or take me, personally, at home - I dislike systemd, and have zero
intention of going up until I have to, and that won't come for a good
number of years yet, when support for 6.x stops. And, btw, no, you cannot
tell me I'm "wrong" to dislike it, that I should "Embrace
Change!!!",
because a) I don't need anyone's opinion to justify how I feel about how
I
deal with something, and b) just because you *can* do something doesn't
mean you *should*. For one example, I do *not* embrace change in the form
of, say, Web-enabled thermostats (and they do security updates exactly
*when*?, or Web-connected cars (are you out of your friggin' alleged
mind?). So, why should I go to something NEW! SHINY! when what I have
works well, and is comfortable?
<MVNCH>
And automatic upgrades are *NOT* always a Good Idea. For example, just
last year, EPEL just upgraded the torque packages that we use to run our
clusters... from 2.5 to 4.2(?!?!?!), which broke the test cluster
instantly, and took a lot of research and work to make work on the test
system by the admin I work with, and on our two big clusters, we're not
upgrading - our users would be down for a while... and these are several
folks running jobs on the (24, 25) node clusters whose jobs can run a week
or two straight.

       mark, down in the trenches, not in a hosting environment

On May 11, 2016, at 9:38 AM, m.roth at 5-cent.us wrote:
> 
> Warren Young wrote:
>> This isn?t just about RHEL vs Debian and
>> derivatives of same.  Several major non-Linux OSes also manage to do
>> automatic upgrades between major releases: Windows, OS X, FreeBSD...
> 
> I was under the impression that all the releases of OS X were more like
> what we call subreleases (6.6->6.7).
You can?t transfer meaning between different version number systems.  There is
no global standard for the meaning of version numbers.  The only thing that
matters is that there is internal consistency.

(Which is why Windows version numbering is a joke.)

OS X treats changes to the ?x? component of their OS X 10.x.y version numbering
system about the same way as EL does in its x.y system.  The only difference is
that major OS X versions have been coming out yearly in recent years, so that
there is less cumulative difference between major versions than in CentOS major
versions.  But there?s probably at least as much change every 3 major OS X
versions, as you?d expect since CentOS major versions are also about 3 years
apart.

And, in fact, OS X will allow itself to be upgraded across major OS versions. 
It doesn?t demand that you upgrade to each intermediate version separately.

Calling OS X major releases ?subversions? is just as fallacious as the opposite
problem we see here in the CentOS world, where some people believe that CentOS
7.1 is incompatible with CentOS 7.2.  A change to y in these two x.y system
means something very different, yet both are correct because both systems are
internally consistent.
>> Your point about the 10 year support cycle for RHEL is also invalid. 
The
>> time spacing between major releases is only about every 3 years, and
that
>> is the period that matters here.
> 
> No, it's not invalid, nor is it what matters. For example, here at
work,
> we have clusters, and a small supercomputer, all running 6.x (in the case
> of the supercomputer, it's an SGI-modified RHEL 6.x), and they'll
go to 7
> probably when they're surplused replaced.
Yes, and??  Just because you have one use case where a major version upgrade
does not make sense does not mean that major version upgrades don?t make sense
everywhere.

I already covered that case in my previous post, and the counterargument remains
the same: not all OS upgrades can be coupled with hardware upgrades.  VMs are
only one reason, though a big one.

As for all the rest of your post, yes, I get it: nothing should ever change,
nothing should ever break.  You just go and live live that dream.  Meanwhile, in
my world, change happens.  Your unwillingness to cope with it does not prevent
me from doing so.

On Wed, May 11, 2016 11:10 am, Warren Young wrote:
> On May 11, 2016, at 9:38 AM, m.roth at 5-cent.us wrote:
>>
>> Warren Young wrote:
>>> This isn???t just about RHEL vs Debian and
>>> derivatives of same.  Several major non-Linux OSes also manage to
do
>>> automatic upgrades between major releases: Windows, OS X,
FreeBSD...
>>
>> I was under the impression that all the releases of OS X were more like
>> what we call subreleases (6.6->6.7).
>
> You can???t transfer meaning between different version number systems.
> There is no global standard for the meaning of version numbers.  The only
> thing that matters is that there is internal consistency.
>
> (Which is why Windows version numbering is a joke.)
And there was a joke about them. When RedHat started pacing fast with
their CD version releases: 7.3 --> 8 --> 9 in very short time, someone
said: they try to catch up with others in major version number. And
someone else pointed: they cant: MS already has Windows 2000 ;-)
>
> OS X treats changes to the ???x??? component of their OS X 10.x.y version
> numbering system about the same way as EL does in its x.y system.  The
> only difference is that major OS X versions have been coming out yearly in
> recent years, so that there is less cumulative difference between major
> versions than in CentOS major versions.  But there???s probably at least
> as much change every 3 major OS X versions, as you???d expect since CentOS
> major versions are also about 3 years apart.
>
> And, in fact, OS X will allow itself to be upgraded across major OS
> versions.  It doesn???t demand that you upgrade to each intermediate
> version separately.
MacOS 10 server (sorry about using Arabic number, I hate using Roman
numbers written with Latin letters, makes any search useless) breaks
things between 10.x versions consistently. They change the way
authentication is done, add, then drop Apache modules, and so on. No, I do
not run any of my servers under MacOS (FreeBSD is current choice,
hopefully for long time to come). But some of Professors I work for do it,
and I have to help them by doing dirty part that comes with it. So: nobody
is perfect (meaning MacOS 10 here ;-)

Valeri
>
> Calling OS X major releases ???subversions??? is just as fallacious as the
> opposite problem we see here in the CentOS world, where some people
> believe that CentOS 7.1 is incompatible with CentOS 7.2.  A change to y in
> these two x.y system means something very different, yet both are correct
> because both systems are internally consistent.
>
>>> Your point about the 10 year support cycle for RHEL is also
invalid.
>>> The
>>> time spacing between major releases is only about every 3 years,
and
>>> that
>>> is the period that matters here.
>>
>> No, it's not invalid, nor is it what matters. For example, here at
work,
>> we have clusters, and a small supercomputer, all running 6.x (in the
>> case
>> of the supercomputer, it's an SGI-modified RHEL 6.x), and
they'll go to
>> 7
>> probably when they're surplused replaced.
>
> Yes, and????  Just because you have one use case where a major version
> upgrade does not make sense does not mean that major version upgrades
> don???t make sense everywhere.
>
> I already covered that case in my previous post, and the counterargument
> remains the same: not all OS upgrades can be coupled with hardware
> upgrades.  VMs are only one reason, though a big one.
>
> As for all the rest of your post, yes, I get it: nothing should ever
> change, nothing should ever break.  You just go and live live that dream.
> Meanwhile, in my world, change happens.  Your unwillingness to cope with
> it does not prevent me from doing so.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

Nothing here. I responded to him on this offlist.

       mark