[glue-wg] When is data stale?

[stephen.burke at stfc.ac.uk]

Paul Millar [mailto:paul.millar at desy.de] said:
> It's circular because you define CreationTime in terms of the time
> something is created.  This is either circular argument or a
> semantically null sentence -- you choose :)

I don't know if you're being deliberately obtuse - *all* the attribute names are supposed to be descriptive of what they mean, if they aren't the name is poorly chosen. Would you be happier if the attribute were called RabbitFood and I defined it as a creation time?

> This may be as-intended, however, it makes defining CreationTime difficult.

No it doesn't. I find this discussion pointless and I don't intend to keep repeating the same things.

> How do you distinguish between information being copied from some other
> BDII and being copied from an info-provider?

I don't, and the BDII doesn't. Either way, if the LDIF contains a CreationTime attribute the BDII stores it along with everything else; if it doesn't the BDII doesn't add it. 

> Do you know if the glue validator is being run against production
> top-level BDII instances?

Yes, it's run as part of the site Nagios tests, and sites get tickets for things marked as ERROR, except that known middleware bugs are masked. I'm not sure offhand if that includes this issue - as Florido says, the ARC values were short enough that they always failed the test so it may still be masked. 

> One hour!  Why doesn't someone fix this?

It's actually more like 30 minutes, and it's pretty much intrinsic to the BDII architecture. There have been various attempts to design a new information system but none have come to fruition.

> > In my info provider it is indeed hard-coded to 1 hour - as I say it
> > would be easy enough to change it, but there's no current demand.
> 
> OK, but why 1 hour and not 1 minute or 1 day?

As I said, there's no point in having it much shorter than an hour because the system can't update that fast. For most dynamic information 1 day would be unrealistically long because the dynamic state of most services can change quite a bit faster, e.g. services often go from up to down to up within a day. Ideally we'd have a more responsive information system and one which treated different kinds of information differently - i.e. fast-changing information like running job counts would be updated every few minutes or less, while slowly changing objects would update infrequently. In that case the Validity could be set according to the realistic lifetime of the information and the information system could use it as a guide to when it should refresh. However that isn't what we have at the moment.

Stephen