[glue-wg] When is data stale?

[stephen.burke at stfc.ac.uk]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
> Behalf Of Paul Millar said:
> Sent: 20 April 2015 11:38
> Stephen: "It would be incorrect, since it would not be the time at which
> the information was created." -- circular argument fallacy: CreationTime
> is the time information was created.

I don't see why it's circular. The BDII doesn't create anything, ergo it should not change the creation time, any more than translating it into XML. I just quoted the timestamp in the snippet of mail above written by you - should I update it to the current time? No, because I haven't changed when you wrote your mail. 

> Florido: "No. CreationTime refers to the record related to the entity
> described. Only the resource provider that creates the datastructure can
> know such time. BDII levels above resource just copy the data." Again,
> straw-man fallacy as it requires GLUE 2 to distinguish between resource-
> and higher-level BDIIs.

I don't understand your point at all here. Let's try again: the creation time is the time the *information* represented in a GLUE object is created. That information may be copied, translated or stored in many different formats, none of which has anything to do with the information itself, i.e. the values of the various attributes. 
 
> However, the difficulty in describing the exact semantics of
> CreationTime suggests (to me) that GLUE 2 _does_ include the concept of
> aggregation, at least because it has CreationTime with different
> processing models depending on whether the agent is a primary data
> source (e.g., Resource BDII) or an aggregating source (Site- or Top- BDII).

The thing which sets the CreationTime is not the BDII at any level, it's the information provider. That is often run by a resource BDII, but not necessarily, e.g. some objects are created by YAIM scripts when a service is configured. All the BDIIs do is read some LDIF from somewhere, store it in an internal database and make it available for query, they don't create any of it.

> My question to Stephen: different clients may tolerate different levels
> of error/uncertainty (is 1% "good enough"?  how about 5%, 10%, or 20%?).
>   Given that "reasonably trusted" depends on the client, how to know
> what value is to be published?

As far as I know we have no clients which make use of it. The only use I'm currently aware of is the glue validator, where the goal is to spot services which are stuck or otherwise faulty. If other use cases arise people would have to look at the details to decide what to do - bearing in mind the constraints of the system, e.g. that the top BDII can't manage freshness of much better than an hour. I don't see that this is different to any attribute - what you publish needs to be driven by the use cases. It wouldn't be especially difficult to publish a different Validity for each object type, or even for e.g. different batch systems, but unless you have something to specify the use there's nothing to motivate such a varying choice.

> So, to a good approximation, only one Validity value is set: 1 hour.
> This narrow distribution suggests that, when set, Validity is hard-coded
> to some value.

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. 

Stephen