SCIENTIFIC-LINUX-USERS Archives

June 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 26 Jun 2014 06:50:06 +0900
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
On Wednesday 25 June 2014 22:41:32 Dag Wieers wrote:
> On Wed, 25 Jun 2014, Akemi Yagi wrote:
> > On Tue, Jun 24, 2014 at 10:29 PM, Yasha Karant <[log in to unmask]> wrote:
> >> I was not referring to the Fedora mechanism.  Some licensed-for-fee
> >> commercial unix environments (not linux) used on primary servers allow
> >> for
> >> major release upgrade in place.
> >> Does the Red Hat method that is mentioned by Red Hat allow for this, or
> >> is
> >> the Red Hat enterprise z-stream "insane" to use in a production
> >> situation?
> >> 
> >> If it is not insane but actually is effective, are there no Linux or GPL
> >> encumbrances on z-stream that "force" Red Hat to release the source?
> > 
> > Please see this documentation:
> > 
> > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linu
> > x/7/html/Migration_Planning_Guide/chap-Red_Hat_Enterprise_Linux-Migration_
> > Planning_Guide-Upgrade_Tools.html
> > 
> > But it is supported only in some use cases. The details are summarized
> > here:
> > 
> > https://access.redhat.com/site/solutions/799813
> > (this one needs subscription to read)
> 
> As I understood it from a Red Hat spokesperson this functionality was
> absolutely required for their RHEV product so that hypervisors could
> be updated from the RHEL6-based product to the RHEL7-based product.
> 
> Quite likely this will be used for other more appliance-like
> (read: self-contained) setups/offerings in the future as well.

This is one of the only safe-ish uses, and only if the *only* thing the host 
does is act as a VM host with an entirely vanilla configuration.

I think a lot of the interest in this is actually coming from desktop users 
who have quite a few customizations floating throughout their systems (not to 
mention external repos involved...) and there is absolutely no possible way 
any vendor could create a tool that reasonably guaranteed that nothing would 
break in the upgrade process (without containerizing everything and actually 
leaving the old system in parallel with the new system -- which is its own bag 
of worms).

Folks should take control of their expectations instead of getting excited 
about this if what they are getting excited about is not having to re-
customize a desktop install in time consuming ways.

ATOM RSS1 RSS2