Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases

[John Reiser]

On 04/09/2012 07:18 PM, Dan Mashal wrote:
> As I said in the meeting let's just deprecate it [in favor of yum+network].

The problems I have seen with using only yum+network to perform a distro
version upgrade are:

  1. It's a poor idea to be running almost anything else on the box
     at the same time as a distro version upgrade.  It is quite likely
     that an app will encounter difficulties because of mismatched versions
     of the components on which it relies.  [For instance, I've run across
     situations where software-initiated reboot *hangs* after distro version
     upgrade; I had to push the reset button.]  Thus single user mode should
     be considered a requirement for distro version upgrade via yum+network,
     although often it happens to work in multi-user mode if the box
     is "otherwise idle".

  2. yum is stupidly slow about collecting the upgrade .rpms.
     First there is downloading itself: yum downloading [of any kind]
     is single threaded.  Often this wastes 30% to 50% of available
     bandwidth (at the server and/or in the pipe.)
     A close-to-optimal strategy for typical cable modem ISP is:
          1. Sort the download list by size of file to be downloaded.
          2. Run two parallel threads.  The first thread downloads
             from large to small, the second from small to large.
             Stop when the threads meet somewhere in the "middle".
     [Debian has a two-thread download for "apt upgrade".  It does not
     use the optimal strategy, but it is still effective.]

     Second, yum does not download the remaining .rpm (whose .drpm
     are not available) while it is reconstituting the other .rpm
     from .drpm.  The waste can be significant for the common case
     when there are enough .drpm for some large .rpms (kernel,
     libreoffice-*, etc.)

  3. If distro version upgrade via yum+network fails (power failure,
     network failure, configuration failure, operator error, ...),
     then you have a big mess.
     The .rpm are not saved, so re-downloading might be substantial.
     If an expert is not available for hands-on analysis and repair,
     then a fresh install might be the best choice to achieve
     shortest down time.

Thus effective downtime can be reduced substantially if preupgrade
manages to parallelize the collection of the anticipated .rpms
(download .drpm and .rpm, reconstitute .rpm from .drpm)
with normal multi-user operation of the machine under the old
distro version.

--