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

On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
> On 2016-05-10, Valeri Galtsev
> <galtsev at kicp.uchicago.edu> wrote:
>>
>> 1. Debian (and clones): you keep the components of the system pretty
>> much on the level of latest release of each of components. Therefore
>> "upgrade" to new release of the system is pretty close to
just a
>> regular routine update.
>
> You are describing Debian sid/unstable, which is contunuously updated,
> and where there are no releases in the usual sense of the word. Debian
> stable releases are a different matter, and correspond very closely to
> major releases of RHEL/CentOS. There is always an upgrade path between
> consecutive releases of Debian stable.
>
Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas
RHEL (hence CentOS) is what, 10 years? I was pretty sure Debian does not
backport patches (of Linuxes no one except RH, as far as I know). How do
they do it with LTS? Do they just freeze major version, no matter what (it
is only 2 years the need)?

Thanks.
Valeri
>
> Liam
>
>
> _______________________________________________
> 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
++++++++++++++++++++++++++++++++++++++++

On 11/05/2016 8:12 AM, Valeri Galtsev 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:
>>>
>>> 1. Debian (and clones): you keep the components of the system
pretty
>>> much on the level of latest release of each of components.
Therefore
>>> "upgrade" to new release of the system is pretty close to
just a
>>> regular routine update.
>>
>> You are describing Debian sid/unstable, which is contunuously updated,
>> and where there are no releases in the usual sense of the word. Debian
>> stable releases are a different matter, and correspond very closely to
>> major releases of RHEL/CentOS. There is always an upgrade path between
>> consecutive releases of Debian stable.
>>
>
> Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas
> RHEL (hence CentOS) is what, 10 years? I was pretty sure Debian does not
> backport patches (of Linuxes no one except RH, as far as I know). How do
> they do it with LTS?
This would be a good question for the ubuntu users list . . .

Ubuntu user technical support,
  not for general discussions <ubuntu-users at lists.ubuntu.com>

Do they just freeze major version, no matter what (it
> is only 2 years the need)?
>
> Thanks.
> Valeri
>
>>
>> Liam
>>
>>
>> _______________________________________________
>> 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
> ++++++++++++++++++++++++++++++++++++++++
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

On 05/10/2016 05:15 PM, phil wrote:

<snip>
> This would be a good question for the ubuntu users list . . .
> 
> Ubuntu user technical support,
>  not for general discussions <ubuntu-users at lists.ubuntu.com>
> 
I agree :)

<snip>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20160510/ec202bed/attachment-0001.sig>

On 2016-05-10, 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:
>>>
>>> 1. Debian (and clones): you keep the components of the system
pretty
>>> much on the level of latest release of each of components.
Therefore
>>> "upgrade" to new release of the system is pretty close to
just a
>>> regular routine update.
>>
>> You are describing Debian sid/unstable, which is contunuously
>> updated, and where there are no releases in the usual sense of the
>> word. Debian stable releases are a different matter, and correspond
>> very closely to major releases of RHEL/CentOS. There is always an
>> upgrade path between consecutive releases of Debian stable.
>>
>
> Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years,
> whereas RHEL (hence CentOS) is what, 10 years? I was pretty sure
> Debian does not backport patches (of Linuxes no one except RH, as far
> as I know). How do they do it with LTS? Do they just freeze major
> version, no matter what (it is only 2 years the need)?
Others have complained that this is not the place for an extended
discussion on Debian, so I'll just direct you here:

	https://wiki.debian.org/LTS/

If you have any questions, I suggest you post them to debian-user. I am
subscribed to that list, and will be happy to resume the conversation
there.

-- 

Liam

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:
>>> 
>>> 1. Debian (and clones): you keep the components of the system
pretty
>>> much on the level of latest release of each of components.
Therefore
>>> "upgrade" to new release of the system is pretty close to
just a
>>> regular routine update.
>> 
>> You are describing Debian sid/unstable, which is contunuously updated,
>> and where there are no releases in the usual sense of the word. Debian
>> stable releases are a different matter, and correspond very closely to
>> major releases of RHEL/CentOS. There is always an upgrade path between
>> consecutive releases of Debian stable.
> 
> Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas
> RHEL (hence CentOS) is what, 10 years?
?LTS? is an Ubuntu term, not a Debian term.  Debian and Ubuntu are very much not
the same thing.  I point this out not to be pedantic but instead because there
are *two* OSes here that both manage to have straightforward automatic upgrades
between major releases.

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...

Take FreeBSD for example.  Its freebsd-update tool will do this, and it?s mostly
automatic, even in the face of changes to core OS files.  (e.g. /etc/services) 
It can even merge changes to a core OS configuration file with your local
version in certain cases.  Or, it can just open both versions in a text editor
and wait for you to merge them manually.  Why can?t there be a rhel-update tool
that does the same?

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.

That is to say, I would not expect an automatic major upgrade tool for RHEL to
let me jump straight from version 5 to version 7 just because RHEL 5 is still
receiving security updates.  The tool only has to be able to upgrade from the
prior major release.

This is a solvable problem.  Red Hat just doesn?t want to solve it.  Why?

The upgrade doesn?t have to be perfect.  It could break everything except the
filesystem and SSH and still allow manual recovery.  Even in that extreme,
you?re still no worse off than today, where you have to migrate everything by
hand.

It is actually an uncommonly good time to make such a tool, with the shift to
systemd behind us.  Unit files are far less likely to cause problems in an
automatic upgrade than Bourne shell scripts that source piles of other Bourne
shell scripts.  An automatic upgrade from RHEL 7 to RHEL 8 should be much safer
than RHEL 5 to RHEL 6.

Another big shift also plays into this: VMs everywhere.

In the past, an automatic major OS version upgrade wasn?t as useful because by
the time you wanted to do a major OS upgrade, the hardware was ready to be
replaced, too.  RHEL?s policy of keeping the past two major versions under
support helped, a lot: if the hardware is still doing what you need it to, you
could skip a major version,  after which the hardware is probably about ready to
fall over, if only because the CPU fan is about to seize up.

In that world, you could do the OS upgrade and the hardware upgrade together,
since you need to migrate the data and services over manually anyway.

VMs are changing that.  The longer that shift continues, the bigger a problem
this missing feature will cause for EL shops.

And that probably takes us to the real reason Red Hat doesn?t want to solve this
problem: the requirement to support automatic major version migration wouldn?t
have allowed them to throw Xen into RHEL 6 and then pull it right back out for
RHEL 7.  I think Red Hat *wants* the freedom to break core OS facilities between
major 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