Dell Customer Communication
--
Matt Domsch
Senior Distinguished Engineer & Executive Director
Dell | Software Group, Office of the CTO
-----Original Message-----
From: Pierre-Yves Chibon [mailto:pingou@xxxxxxxxxxxx]
Sent: Monday, June 29, 2015 4:19 AM
To: Fedora Infrastructure
Cc: Domsch, Matt
Subject: Re: Thoughts and question about MM2's UMDL script
On Fri, Jun 26, 2015 at 01:45:01PM -0600, Kevin Fenzi wrote:
> On Fri, 26 Jun 2015 21:00:37 +0200
> Adrian Reber wrote:
>
> ...snip...
>
> > > > * Readable status of directories The Directory table has a
> > > > 'readable' property, none of our directories is not readable.
> > > >
> > > > Question is: what is the use-case for this boolean?
> > >
> > > Could it be for when we have a release about to come out, but it's
> > > not readable to the public yet? Typically we stage a release on
> > > friday and until the actual release on tuesday the directory isn't
> > > open, only mirrors with the acls can sync it.
> >
> > Yes, that's also what I remember about it. Although I am not sure if
> > we still need it. As we bitflip much earlier we have the chance to
> > crawl everything before the release. The last few releases we even
> > didn't use the data under releases but under development for the
> > first few weeks. So this functionality has become pretty useless
> > with the current release mechanism.
>
> I'm not sure I agree. ;)
>
> We stage a release friday with the directory closed.
> True, we have been doing the bit-flip sooner, but usually it's late
> monday night so more mirrors will be synced for the release tuesday
> morning.
>
> So, if we remove this, what happens friday->monday night?
> ie, what does property do? Does it use the info for seeing if
> something is up to date, or just if it's set it doesn't give out
> metalinks with those paths? or ?
Matt, do you remember how the 'readable' property works?
== MD == Recall there are 2 ways a host_category_directory entry gets created. 1) crawler; 2) report_mirror. Readable=False is a flag so that crawler doesn’t mark directories as not up2date or mark for deletion just because it can’t read them pre-bitflip,
having been created by report_mirror. In a sense, HCDs pointing to directories with readable=False is foretelling the future state of the mirror list (what will be reported as soon as the bitflip happens and UMDL sets readable=True) without having to wait
for the crawler to hit a given mirror or for that mirror to run report_mirror again.
