[glue-wg] Publishing annotations

[Paul Millar]

On Monday 07 April 2008 17:50:27 Burke, S (Stephen) wrote:
> > [moving towards using annotations]
> 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).

OK.  My (personal) preference would be to stay as-is for now: have 
info-providers publish information that is limited in scope to what they can 
(with some authority) say and (as far as possible) group this information 
into classes that do not overlap with ones that other info-providers publish.

> > [...] (I didn't realise FoC was published into GLUE like this),
> FoC isn't publishing into Glue as such, what it publishes (on [...]

Ah, OK.  Thanks for the info.


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

Aye,

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

Well, I don't think this is so specialised.  In general, a UserDomain might 
want to mark any Service as "Sane" (i.e., has been tested).  This isn't 
limited to any specific type of service.

In essence, it's just recording the output of the SAM tests (and FoC, if 
different) within GLUE.

> Actually in practice I doubt it will happen, it would be too 
> much effort for something which already works reasonably well.

True.

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

Ah, OK.  Sorry, I thought GLUE had these fields 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).

Yes, I meant to ask out of idle curiosity: why is this?  If an SE unavailable, 
(drops out of info-system) it's almost necessarily unavailable.  Why does FTS 
care about it?


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

Well OK, but the problem is (to my mind) that that process is broken anyway:  
use the info system to discover how to ask the info system.

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

Yup, fair point.


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

Yes, and that's where (in an idea world) the GOC DB might act as a cache for 
the down-time information published through Glue.

(... meanwhile, back in reality)

Cheers,

Paul.