[glue-wg] Publishing annotations

[Paul Millar]

Hi Stephen,

I don't think "dCache" has a strong opinion on this.

I'm not sure I do, either, but my initial thoughts are that annotations are 
not the right solution here as they don't fit in with how the rest of GLUE is 
structured.

More comments interleaved below:

On Monday 07 April 2008 14:32:20 Burke, S (Stephen) wrote:
[...]
> The specific thing I was considering was the EGEE "freedom of choice" tool,
> which currently edits the published data by removing
> AcessControlBaseRule attributes for CEs which are failing defined tests.
[...]

Yes, removing information definitely sounds like a hack.

Personally, I'd say the correct approach is that, should ATLAS wish to publish 
information (I didn't realise FoC was published into GLUE like this), it 
should do so as well-defined objects rather than as annotations to existing 
objects.

The AccessControlBaseRule is set by a site, say that they believe that they 
support a UserDomain (ATLAS, for example).  The site is authoritative in that 
statement, no-one should create or alter that information.

If the UserDomain (e.g., ATLAS) wants to record that a service is broken for 
them, that should be recorded elsewhere---somewhere where the UserDomain is 
authoritative.  Alternatively, the UserDomain could publish the services it 
has checked as working (e.g., within EGEE, via SAM).

For example, there could be a ServiceBroken (or similarly named) object that 
records that some UserDomain (e.g. ATLAS) found the service unusable.

Alternatively, the UserDomain could publish a CertifiedSane object that links 
a UserDomain (ATLAS, ops (for SAM tests), etc.) to a Service.  In effect, 
publishing this object saying the service "works for me".

CertifiedSane objects assumes a default-broken model (a service must prove 
itself) whereas a ServiceBroken object assumes a default-working model. One 
would hope that publishing ServiceBroken objects would take less storage.

Clients can choose to ignore these ServiceBroken / CertifiedSane objects; 
e.g., the ATLAS testing framework could ignore it whilst normal ATLAS jobs 
look for it.

>   Another thing that occurs to me on similar lines is the downtime
> information. I see that this is now embedded in the Endpoints, but for
> EGEE that wouldn't be usable because our downtime information is in a
> central database (GOC DB), so if we wanted to publish it it would again
> need to be done by modifying/annotating published information from a
> different place.

I believe this is a long-standing issue that arose for two reasons: first, it 
was "difficult" for a site to publish down-time through GLUE; second, if a 
site is going into emergency down-time (a JCB has just cut the fibre-optic 
link), then publishing information through GLUE would be difficult.

The first one is (I think) purely an implementation issue.  If the information 
was readily available, then GOC could switch from being definitive to acting 
as a cache for the information published by the site ... but this is really 
an EGEE decision.

For the second issue, I'm not sure what the correct solution is here.  
Perhaps, with most technologies, the site should drop out of the info. 
system, which would be "good enough".

>   This could maybe also feed into our CESEBind discussion, e.g. rather
> than the CE and SE publishing disconnected pieces of information the CE
> could in effect add/modify things published by the SE, i.e. we could
> separate the schema structure from the question of who publishes it.

Hmmm, not completely sure about this.

I believe we currently assume that an object is published by a single 
component.  Maybe this needn't be an assumption, but I'm not sure how well 
the different underlying storage technologies would handle this 

I suspect, in most cases, we would need to split the information anyway into 
the different subsets to allow partial results to validate correctly 
(objectClass in LDAP, XSD types with XML, etc).  If this is so, then (in 
effect) we've split the object into parts, whether we label them as separate 
objects or not.

>   What do people think? Maybe it's too complicated to fit in at this
> stage, but it might be worth a bit of thought - at the abstract schema
> level it wouldn't necessarily mean huge changes. Just thinking about it
> quickly I suspect the problems would come at the implementation level,
> e.g. in LDAP the annotations would still be in a different part of the
> tree so it would take some extra effort in queries to find them.

I'm not sure annotations really gains us much, but I'm also willing to be 
convinced differently :-)

HTH,

Paul.