up2date and yum: failover mode?

[seth vidal]

> 
> The repositories are the same - they are just potentially out of sync.

END.

If they are not in sync then they are not the same.
If they are the same, then they don't need to both be listed as separate
repositories.


> The aim is to maximize acces to local/close/deep mirrors without losing
> ability to get the latest parts from the master site (accessing the
> master site is costly for the upstream source and potentially for the
> user if it means leaving an intranet through a congested shared pipe).

You're mixing the concepts of repository and mirror in ways that they
shouldn't be mixed.

a repository is a set of packages - distinct from any other repository
in that it provides different items - they don't have to be discretely
different but at least not claiming to provide the identical things.

a mirror is an IDENTICAL COPY - hence the term mirror.

in yum it works like this:
[repo]
baseurl=mirror
        mirror
        mirror
        mirror

[repo2]
baseurl=mirror2
        mirror2
        mirror2
        mirror2


> All the download manager should need is a list of the X upstream level 1
> sources, a list of all known mirror sources (sometimes a few 100 sites)
> and be able to choose by itself 2-3 mirrors it'll poll and one upstream
> source to check for completeness.

and if they're not in sync it will never know what it's getting - the
suggestion that you appear to be saying is allow repo2 to provide
something if repo fails.


> What mirrors to hit can be determined with response time checks and
> keeping stats on the bandwidth achieved/level of freshness of previous
> accesses. (keeping track of the access hours might be smart too since
> net topology radically changes when the US wakes up for example, plus by
> correlating relative freshness with dates the program might even learn
> each mirror sync hours over time)

again - this is all about the failover of identical mirrors. That's fine
- and that is why you can add options/cases to failover for that class -
look at failover.py in yum.

however, providing multiple repos that provide mostly the same thing and
expecting repo1 to failover for repo2 is a misuse of the concept.

> All those checks are what a user is supposed to do manually before
> putting a particular mirror in his config file. There is no reason
> automating it can not give better results and produce more efficient
> ressource usage patterns for everyone.

as long as a mirror is a mirror and not an alternate repo then listing
multiple mirrors under a repository stanza and doing statistic tracking
on them is not unreasonable. The tracking is not implemented and will
take some time to implement correctly.

-sv