Thoughts and question about MM2's UMDL script

[Matt_Domsch at Dell.com]

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 at pingoured.fr]
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.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20150629/e88f2b3c/attachment.html>