Mailinglist Archive: opensuse-features (82 mails)

< Previous Next >
[Fate 302923] handle redirection to mirrors robustly
  • From: fate_noreply@xxxxxxx
  • Date: Mon, 14 Jul 2008 13:48:34 +0200 (CEST)
  • Message-id: <1943958494.150261216036114751.JavaMail.tomcat@xxxxxxxxxxxxx>
Feature changed by: jkupec
Feature #302923, revision 11
Title: handle redirection to mirrors robustly

openSUSE-11.0: Rejected by visnov@xxxxxxxxxx
reject date: 2007-11-28 15:42:20
reject reason: Out of scope for 11.0
Priority
Requester: Neutral

openSUSE-11.2: New
Priority
Requester: Neutral

SLED-11: Rejected by visnov@xxxxxxxxxx
reject date: 2008-07-08 12:13:52
reject reason: Postponing, will not be ready.
Priority
Requester: Neutral

SLES-11: Rejected by visnov@xxxxxxxxxx
reject date: 2008-07-08 12:13:49
reject reason: Postponing, will not be ready.
Priority
Requester: Neutral

Requested by: jkupec@xxxxxxxxxx
Partner organization: openSUSE.org

Description:
The proposal is to try other mirrors from a mirror list (from the
redirector?) if an error occurs on some of the mirrors while providing
a file from http/ftp repository. See the references for more details.

References:
https://bugzilla.novell.com/show_bug.cgi?id=337410
http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html
+ http://en.opensuse.org/Libzypp/Failover
+ http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06

Discussion:
#1: coolo@xxxxxxxxxx (2007-11-20 11:15:49)
I would be strictly against having an own mirror list. The decision was
to go with the redirector (or NCC for SLE) and be done with mirrors. If
that does not work, then we have to do this whole thing again, not
adding untested work arounds to the product.

#2: coolo@xxxxxxxxxx (2007-11-20 11:16:55)
so I would reject this. But it's basically "Eval by Klaas" now

#3: freitag@xxxxxxxxxx (2007-12-03 09:49:44)
I agree with Coolos and Peters statements, I would also reject.

#4: freitag@xxxxxxxxxx (2008-06-12 10:06:42)
I have to revert my statement that I made before in comment #3, this
problem is more serious than realised in the first look.
First, it should be noted that we do not control mirrors nor we do have
the chance to really influence them. That means that if a mirrors
decides to not longer mirror or to switch off or whatever, we have to
live with it. However if a customer is sticky to a mirror that is not
longer available he would not get any packages from it and thus
installation or update fails. The worst thing about that is that this
seems to happen regularly but we do not realise that because we're not
involved.
A solution would be to have a list of possible mirrors that is used by
the software installation stack to find a working mirror. Peter knows
much more here.
But I am not sure at the moment if not Yast/zypper already has this
functionality in 11.0?



--
SUSE Feature Tool:
http://partnerfate.suse.de/?rm=feature_show&id=302923

< Previous Next >