Hi Stephen, On 21/01/14 16:40, stephen.burke@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@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.