> On Tue, 26 Jul 2011, Mike Burger wrote: > >> If IBM can make this happen for their OS, and Red Hat certainly supports >> such a process in the Fedora line of releases (including the ability to >> list additional repositories for remote installation as part of the >> process), they could certainly make it a supportable option for the RHEL >> line. > > The upstream supports nothing as to Fedora, and indeed, > members of that project regularly (and seem to gleefully) > break forward compatability I can not believe that the upstream does not guide/provide direction with regard to the Fedora project, given that the Fedora project is still the test bed for what eventually goes into the upstream's commercially supported product. > But you are missing the point -- WHY spend the engineering > effort on trying to support such Major 'upgradeany's? A new > deployment takes mere minutes for a commercial shop, and by > NOT supporting such explicitly, the upstream avoids much > support and engineering load. Quite simply, because the customer base, which is paying the upstream for support, is requesting that such a process be supported. Quite simply, as well, because the upstream is selling the customer on the idea that their product is an enterprise level product. Other enterprise level *NIX providers support this process...the customer may reasonably expect that this provider do the same. Sure...it may take only a few minutes for a commercial shop to deploy an OS, it takes that shop much more time to have to reinstall and reconfigure the applications that run on those OS instances, test, cut over, etc. Additionally, not every shop is running their entire Linux infrastructure in a VM based environment. For those running physical systems, the hardware may still be within their viable hardware lifecycle, but be in need of a newer version of the OS. Should the customer have to purchase an additional physical system for each instance of their OS that must be upgraded from one major release to the next? Where would that leave the customer, as far as having been sold on the cost effectiveness of their Linux installs vs other commercial *NIX offerings? How about those virtualized environments? Spinning up a new VM environment to eventually replace the existing VM with a new OS instance may also require the purchase of additional hardware, in an effort to support the temporary resources needed to spin up, configure and test the new instances prior to putting them into live use. The cost of testing and then supporting live upgrade scenarios, born by the upstream, would likely be less than the cost to the customer base in potential hardware and manpower cycles, and would undoubtedly build the upstream more good will from the customer base. Consider, again, that the feature to perform an upgrade (and not via a hidden upgradeany command line option) is available in the version of Anaconda (the installation tool used by the upstream) that is in use for Fedora intallations and upgrades, and that particular compilation of Anaconda does include the ability to specify those third party repositories from which one may have installed packages. It may be compiled out of the binary that is in use by the upstream, but any of us who have also used their test environment know that it's there, and are more than aware that the upstream has and continues to disable certain features of various included tools when shipping those tools in their commercially supported distribution. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit: https://www.bubbanfriends.org/mailman/listinfo/site-update or send a blank email message to: site-update-subscribe at bubbanfriends.org