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

[Dan Mashal]

1) Yum should be intelligent enough to recognize this

2) yum-plugin-fastestmirror solves this problem.

3) I think we all upgraded from 14.4k modems a few years ago.

Dan



On Mon, Apr 9, 2012 at 8:35 PM, John Reiser <jreiser at bitwagon.com> wrote:

> 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.
>
> --
> --
> test mailing list
> test at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20120409/ba6747ea/attachment.html>