[glue-wg] glue2 cloud examples

[stephen.burke at stfc.ac.uk]

Warren Smith [mailto:wsmith at tacc.utexas.edu] said:
> I don't really understand your comments below - you seem to be putting
> me in the position that I see you in: I'm suggesting that we use GLUE 2
> as it is (and I described how I did that for IaaS clouds) while this
> proposal is to make some major additions to GLUE2 to support clouds.
> All I was wondering was that if we want to make such major additions,
> whether it would be better to rework the GLUE 2 model to better support
> them and similar situations. I'm perfectly fine not doing this.

There's a world of difference between a GLUE 3 which would make backward-incompatible changes to existing objects, and a 2.1 revision which adds new objects and/or optional attributes to existing objects. The latter can be done as an incremental change with new code only required for things which explicitly know about the new things, while the former would need new code everywhere and a long and carefully-managed transition process as we've just had for GLUE 1 to GLUE 2.

> If we want to create a GLUE 2.1 to standardize some cloud extensions,
> then why don't we consider how I represent IaaS clouds as my counter
> proposal. We can see if we can reach consensus on some middle ground
> (which might be using existing GLUE 2 entities with Extensions where
> possible and adding a few new entities where there isn't any fit in the
> current model).

Within the existing GLUE 2.0 anyone can use Extensions or OtherInfo attributes to publish extra attributes not defined in the schema, and indeed EGI already has quite a few of those. However, those are by definition not standardised, they're project-specific. If we want to standardise them they need to be turned into real named attributes and defined in a 2.1 revision.

Whether we need new objects is a matter for discussion, it depends on how much overlap there is between the existing Computing Service objects and what's desired for cloud services. For example, ComputingShare has 43 attributes - if a cloud equivalent would use only 2 of those and would define another 35 cloud-specific attributes then it would seem more natural to have a new object. On the other hand, if most of the existing attributes still make sense and only a few new ones are needed then re-using the objects may be OK. However, if we're making a 2.1 revision anyway it isn't especially harder to create new objects than add attributes to existing ones. Also bear in mind that you need to consider object relations as well as attributes - if the existing objects are re-used you need to be happy with all the relations too. And trying to do a mixture, e.g. keeping most Computing Service objects but defining a new CloudShare object, is likely to be messy, the way we've done the derivations so far doesn't allow for that.

Stephen

-- 
Scanned by iCritical.