[Mageia-dev] Mirror tree structure

[andré]

Romain d'Alverny a écrit :
> On Wed, Oct 20, 2010 at 18:34, Olivier Thauvin
> <nanardon at nanardon.zarb.org>  wrote:
>    
>> Now come the question: "what is a valid mirror ?", eg, what a mirror
>> should have as file to be valid ?
>>      
> Not sure if we discussed in depth MirrorBrain
> (http://www.mirrorbrain.org/ ) for managing mirrors index and
> redirections.
>
> If we were going to use it, could we, for instance, leave mirrors some
> liberty to mirror what branch they want (with some guidances and
> preferences of course) and let our MirrorBrain instance check and
> build the list of valid mirrors for the file actually requested?
>
> This, provided that _consistent_ branches of the tree are mirrored,
> and not only a file here, a file there.
>
> On one hand, this would introduce at least to other things to check:
>   - having enough distributed mirrors that map the whole tree;
>   - having download/install tools take this into account.
>
> On the other hand, this could allow more mirrors to take part in this,
> in that it may require less storage space and less bandwidth usage.
>    
This is an excellent idea, at least to some degree.
Many users (like myself) like to download ISOs, which like the release 
repositories, will change every 6 months (or whatever the release period).
Otherwise they remain static, which means no maintenance for the mirror 
sites.
These elements tend to have relatively large space requirements.
As well, they would have a very large demand (bandwidth) at release 
time, to lessen considerably afterwards.

The update/backport/testing/debug repositories (or whatever Mageia will 
call them) are considerably smaller, but in constant flux, thus 
requiring regular updates on the mirror sites.
These transient repositories would tend to have a relatively constant, 
lower bandwidth demand.

So at least static/transient would be a natural separation.
As long as the division is by Mageia's repositories, it should be 
workable if mirrors select repositories on other bases.

I think it would be useful to keep the update/backport repositories 
together, since they are likely to be used together, and maybe all 
transient repositories.
Having the ISOs on separate mirrors should cause no problem, as users 
are likely to download an ISO by itself, one at a time.

> It's not the only reason to use MirrorBrain anyway, but I wondered if
> this could be a complementary reason.
>
> Not sure, insights welcome.
>    
After a quick look at the MirrorBrain features page, I say let's get it.

There is a problem with the current Mandriva mirror system, using Rpmdrake.
I'm in Montréal, and the nearest Mandriva mirror is not very reliable.  
It also allows only one direct download at a time.  So when I download 
ISOs, I go directly to another mirror, use multiple connexions, to 
download the ISO relatively fast, which is fine.

For updates and incremental downloads it is much easier to use Rpmdrake.
However, often, after having selected a package, I get an error message 
saying the package could not be downloaded because of a problem with the 
mirror site.
(I suspect that usually the site is just not in sync.)

MirrorBrain seems to be the perfect solution for this problem, as well 
as dealing with partial mirrors.

Interestingly, if for some reason a mirror site cannot carry a 
particular package because of restrictions imposed by the country where 
it is located, MirrorBrain will be able to cope.  So that simplifies the 
problem of dealing with legislative/copyright/patent restrictions as well.

So at least 3 reasons to get MirrorBrain :)
> Cheers,
>
> Romain
>    

my 2 cents

- André (andre999)