[glue-wg] Publishing annotations

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Paul Millar said:
> 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.

That's certainly true, but we can in principle change the structure.
Actually I think at the abstract schema level it's almost trivial, the
only real wrinkle is that you couldn't simply publish the existing
object types, you'd need modified versions with all attributes optional
and probably with UniqueIDs changed to LocalIDs (at least semantically).

> 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), 

FoC isn't publishing into Glue as such, what it publishes (on a web
server) are LDAP edits which are applied to top-level BDIIs behind the
scenes, with the effect that some attributes published by the sites
vanish from queries. My suggestion is essentially to make those edits
visible and optional (and independent of LDAP).

> it should do so as well-defined objects rather than as 
> annotations to existing objects.

As it stands that wouldn't work because it doesn't fit with how the
broker does the matchmaking. In principle that could be changed in the
kind of way you describe - but you'd then have a special-purpose
solution for this specific case rather than something which would work
in general. Actually in practice I doubt it will happen, it would be too
much effort for something which already works reasonably well.

> 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; 

It's more that glue never considered it as a use case in the past.

> 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.

Indeed - although the persistency of information when services are down
is another question anyway, e.g. the FTS would like to continue to know
about SEs even when they're down (currently done by writing a cache
file). Similarly it might be nice to be able to select a fall-back BDII
when your main one is down, so you query the info system to find one ...
which doesn't work if you don't have a cache.

> The first one is (I think) purely an implementation issue.  

To some extent, but the GOC DB is now deeply embedded and is not going
to change in practice. Given the general reduction in manpower for grid
projects things that are "just implementation issues" may well be major
obstacles!

> 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".

On the face of it it isn't really good enough for downtime information
to be unavailable when the service is down! (Although of course the
recent power cut at RAL which hosts the GOC DB made that rather
problematic ...)

Stephen