glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@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