Mailinglist Archive: opensuse-buildservice (284 mails)

< Previous Next >
Re: [opensuse-buildservice] Redirector issues.
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Tue, 9 Oct 2007 09:06:46 +0200
  • Message-id: <200710090906.46880.adrian@xxxxxxx>
On Tuesday 09 October 2007 03:10:10 wrote Benji Weber:
> Greetings All,
>
> The redirector is causing problems again. Now with installation for many
> users.
>
> Some of the mirrors are broken or under heavy load, but the redirector
> is still redirecting people to those mirrors. This coupled with the
> fact that the openSUSE installer now selects "use online repositories"
> by default (a good thing) means that many people are experiencing
> failed installations.

I would be happy, if you can name some ;)

> The real problem is the mirror "sticky" that means people always get
> the same mirror. This means that if the user gets a bad mirror and a
> package download timeout then the installation has essentially failed.
> If the user clicks retry he/she will get the same mirror, and a
> timeout again, and again. There is approximately 1minute timeout
> between attempts, and several hundred packages to install from online
> sources by default. This means even if the user clicks "skip" for each
> package it will take hours to complete the install. So the install has
> effectively failed because of the redirector's mirror sticky.
>
> Quite a number of users have commented on this behaviour, I have
> experienced it myself with 2 installs already. It has also been
> mentioned in some reviews, contributing to overall bad reviews of
> 10.3.

Do you you have URLs ?

> Other distribution's solutions:
>
> 1: Round Robin DNS
> + No problem with redirector server going down
> + If one of the mirrors in rotation is broken clicking "retry" will
> likely select a good mirror.
> + Location based mirror selection not possible but can have e.g.
> eu.download.opensuse.org, us.download.opensuse.org ... etc
>
> - Frequently changing repositories such as on the build service, could
> bounce between new metadata & old packages and vice versa.

- no check if a mirror is complete
- no possibility to disable a mirror fast, when it goes down
- no support for mirrors which provide only a subset of files (what are quite 
a lot)

> 2: Mirror list files
>
> Other distributions use mirror-list-files which the package manager
> interprets.
>
> + No sticking-to-bad-mirror problem of the redirector.

well, this is more a client side task, a client can already request the list 
of mirrors which provide a certain file.

So it would be thinkable, that libzypp checks this list and asks for another 
mirror if it got an error.

This would have the advantage that we get also broken or unreliable mirrors 
reported from the clients and can do some actions like disabling or rating 
them down.

> + Avoids the bouncing between mirrors problem of RR DNS.
>
> - The server with the mirror list on needs to be up when it is requested.
> - Cannot be achieved without modifying the client package management
> software.

yep :)

Klaus, Duncan, any comments from your side here ?

>
> Sticky breaks installations, no sticky breaks general package
> management - what is the solution? Can the redirector do better
> checking on mirror availability and status? any thoughts? A solution
> that can be achieved by only modifying d.o.o so that future 10.3
> installations can go smoothly is obviously preferable.

well, no sticky means just that we would get unreproducable errors and random 
points. This is IMHO even worse, since it is hard to find out which mirror is 
actually broken.

So in short, I see to options on the high level

* Either we can guarantee for only non-broken mirrors (or at least for a 
  reasonable level)
* We can handle broken mirrors on the client side.

But the discussion about sticky or not sticky is only moving the problem IMHO.

bye
adrian

-- 

Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian@xxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
References