[glue-wg] Notes: GLUE WG session at OGF 40

[Paul Millar]

Hi Stephen,

On 21/01/14 16:40, stephen.burke at stfc.ac.uk wrote:
> Paul Millar [mailto:paul.millar at desy.de] said:
>> I may have missed this, but has anyone attempted to describe the
>> Cloud instances using GLUE 2.0 and the built-in extension points?
>
> To some extent; have a look at this, which is a commercial cloud
> provider which has recently joined EGI:
>
> ldapsearch -x -h site-bdii.100percentit.com -p 2170 -b
> GLUE2GroupID=cloud,o=glue
>
> That information isn't yet integrated into the top BDII, but the plan
> is to have that fairly soon.

Nice.

>> It would be useful for us because we designed extension points to
>> support exactly this use-case.  If it turns out that Cloud
>> services cannot be described in GLUE 2.0 then our extension system
>> is broken and should be updated with GLUE 2.1
>
> The extensions are designed to let you add new attributes to existing
> objects, they were never intended to let you build a whole new set of
> objects.

I wasn't aware that we had excluded that possibility, but perhaps it 
comes down to how one defines "new set of objects".

 From the spec. it is legal to publish Entity (at least, nothing says 
you can't) and many of the top-level classes (Service, Share, etc). 
Publishing Domain is expressly forbidden, however.

Looking at a (possibly old) copy of the LDAP schema, I see that 
GLUE2Entity is declared ABSTRACT and GLUE2Service and GLUE2Share are 
declared STRUCTURAL, so publishing GLUE2Service is allowed (and actively 
used) but publishing GLUE2Entity isn't allowed.

If the "new set of objects" may be described in terms of these top-level 
objects (Service, Share, etc.) then new kinds of object may be published 
without schema update.

Since Entity has no strong semantics, if Entity was STRUCTURAL instead 
of ABSTRACT then we could allow almost arbitrary objects to be 
published, and still provide the same GLUE2 linking and querying abilities.

So, we might want to revisit making Entity ABSTRACT in the LDAP schema.

(IIRC, there were good reasons for making it ABSTRACT, but I don't 
remember them :-)

Cheers,

Paul.