On 06/25/2014 01:26 AM, 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_Linux/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)
>
> Akemi
Although this issue evidently is not of interest to some participants in 
this list, it may be to others.  I read the public documentation, and 
everything seems the norm with many commercial unix technologies that 
provide similar functionality.  In a worst case, quoting from the public 
document:

Data that could be used for "cloning" the system, if the in-place 
upgrade is not suitable.

end quote

that presumably means reminding one of which files/directories must be 
preserved on a "partition" that will not be touched (the usual method 
whereby one must reformat the partitions that will be used for the core 
system environment, such as /boot and /usr, etc., and vital 
files/directories from these areas must be copied to areas that will not 
be "touched").  We do keep such a list and do this copying operation 
manually, but we have missed things in the past, having gone through a 
number of major release upgrades over the years.

Unfortunately, I do not have access to a Red Hat subscription. Without 
quoting, and thus presumably violating access restrictions, would some 
who does have such a subscription kindly summarize (re-word) the use 
cases in which the upgrade-in-place mechanism that Red Hat marketing so 
touts actually cannot be used?

Yasha Karant