[glue-wg] Call for minor non-distruptive updates to GLUE 2.0

[Paul Millar]

Hi Stephen,

On 08/09/14 17:36, stephen.burke at stfc.ac.uk wrote:
> Paul Millar [mailto:paul.millar at desy.de] said:
>> As I said, my vote would be for a "Profile" attribute, but I would
>> like it to combined the EGI ProfileName and ProfileVersion into a
>> single attribute.  One way of doing this would be to combine the
>> two values with a dash (e.g., OtherInfo: ProfileName=EGI,
>> OtherInfo: ProfileVersion=1.0 becomes Profile=EGI-1.0).
>
> In general we try to avoid having multiple pieces of formatted
> information in a single attribute - the main case so far is
> InterfaceExtension where we have yet to find a way to define or use
> it!

It kinda depends whether or not you consider "EGI-1.0" a formatted piece 
of information; it could be an opaque identifier, like "NorduNET" in my 
examples.

 > Also I'm doubtful if it means anything to support multiple
> profiles given that in general they will have conflicts.

Yes, that could be a problem; but it could also be that XSEDE, EGI, OSG 
(three names chosen at random) could have sufficiently large overlap in 
their profiles that a service could publish information that is good for 
all three profiles.

AFAIK, currently there is only the EGI profile, so we're speculating here.

 > You could perhaps have a ProfileExtension attribute ...

What semantics would that have?

[...]
>> True: requiring clock synchronisation isn't great.  Also, it seems
>> nobody is really using the Downtime* attributes; at least, not when
>> I checked (perhaps nobody was in down-time just then!).
>
> In EGI the current situation is that downtimes are managed by the GOC
> DB - but of course that has now adopted GLUE 2 as an information
> model so it would be good to bring things in line, whatever we do in
> the BDII. As things stand there is no easy way to import GOC DB
> information into the BDII information providers - potentially you
> could have some kind of unified interface but it seems unlikely that
> it will happen in practice (the work on the LCG registry was
> terminated due to lack of interest).

Could GOCDB itself inject the information?

That would need the concept of an info-modifier: an info-provider that 
modifies information published by some other info-provider.

That concept would be useful elsewhere; e.g., UserDomain and VOMS servers.

> In any case the situation with the cloud may be different - managing
> downtimes for transient services via the GOC DB, which requires
> static registration, may not be possible. On the other hand, do
> transient services even have a concept of downtime?

Who can say?

But I think "transient" is in the eye of the beholder: with cloud, 
services could be up for months, if not years.

Or the downtime could be that of the cloud-provider itself, much like a 
CE registering downtime for an upgrade.

HTH,

Paul.