Subject: | |
From: | |
Reply To: | |
Date: | Thu, 26 Jun 2014 06:50:06 +0900 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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.
|
|
|