[glue-wg] Extending GLUE 2.0 for Cloud services

[Salvatore Pinto]

Hi Paul,
answers inline.

On 04/11/2013 18:15, Paul Millar wrote:
> Hi Salvatore,
>
> On 04/11/13 13:58, Salvatore Pinto wrote:
>> The first proposed draft is attached. We would really appreciate your
>> comments and maybe to add a point for discussion in the next WG meeting.
>
> Thanks for posting the document.
>
thank you a lot for the comments :)
> I haven't really gone through it in detail, so these are just some 
> initial observations.
>
> First, it looks like you have inserted the word "Cloud" as a prefix to 
> every class in the document.  This isn't an extension, but a complete 
> rewrite!
>
I named it extension, because it inherits the same main entities and and 
similar conceptual model from GLUE 2.0, so I considered it an extension 
to the standard. Sorry if I was wrong on that, maybe it is indeed an 
"addition" more than an "extension".
> Second, GLUE 2 contains extension points to allow communities to gain 
> experience with new information without requiring the change of LDAP 
> (or other) schemas on deployment machines.  If you haven't already got 
> operational experience of the cloud extensions then you really should 
> consider using these extension points first.
>
we considered this option, but, for Compute, we have also some change in 
the relationships between the objects and mandatory attributes in the 
Grid elements which have no sense in the Cloud world.

Anyway, the main reason for not using the extension was that, 
considering the different kind of services the Cloud and the Grid are 
giving to the users, we wanted to keep the entities separated.
> Third, some of the objects show no additional information beyond the 
> existing GLUE 2.0 definitions; for example, the 
> CloudStorageAccessProtocol seems identical (from memory) to the 
> StorageAccessProtocol.
>
That is true, Storage schema is very close to the Grid version and can 
be indeed rewritten inheriting the Storage elements or just modifyi-ing 
them. From my point of view, the big difference between Cloud and Grid 
storage is that Cloud storage is not file-oriented like the grid one but 
more object oriented (where an object can be a file, a disk image, a 
stream or a generic object). So, in this view, the "Grid" storage is a 
specialization of the "Cloud" one (where object type=files) and it would 
be probably better to change the GLUE 2.0 Storage element to consider 
objects instead of files and have one single entity. What do you think 
of that?

> Fourth, the inheritance model seems broken.  Many classes show 
> considerable overlap with their non-Cloud equivalents: 
> CloudStorageServiceCapacity has TotalSize, FreeSize, etc, but also 
> StoredObjects.  As the cloud versions do not extend from the non-Cloud 
> classes, a publishing system would have to publish twice as many 
> objects (the Cloud ones and the non-Cloud ones).
>
as I said before, Storage objects are taken completely from the 
non-Cloud ones and we wanted to have twice the objects to keep Cloud and 
Grid services separated.
> NB that inheritance isn't the solution to this problem; rather, you 
> should have non-overlapping attributes.
>
> Fifth, have you considered what is current state-of-art within the 
> cloud ecosystem?  Talking specifically about storage, you should look 
> at what already exists.  In particular, CDMI provides a 
> standards-based interface for interacting with cloud storage.  It 
> includes specific metadata about a storage system.  I suggest you look 
> at this metadata as a source of inspiration.  NB. I'm NOT suggesting 
> you copy all the metadata from CDMI into GLUE 2!
>
CDMI metadata are mostly related to file-level options, for example 
ACLs, file redundancy, file encryption, etc... (source: 
http://cdmi.sniacloud.com/cdmi_spec/16-metadata/16-metadata.htm). We 
could try to extend these attributes at system level and assign them to 
the storage service or other entities, but with this we would break one 
of the main features of the Cloud storage, which is the freedom for the 
user to ecrypt one file and not another, share one with the world, one 
with only his colleagues and another restricted. We could add anyway the 
"Support for Data system Metadata", for example 
FileEncryptionSupported=[yes/no], etc..., I will think about that.
> Finally, please be careful that any additional publishing fits in with 
> existing storage systems.  Grid and cloud are not two mutually 
> exclusive worlds; with dCache, for example, we have software where a 
> single storage instance can provide both grid- and cloud-like 
> storage.  It should be possible for such systems to publish themselves 
> without doubling the number of objects.
>
again, one point for modifying the original Storage elements to consider 
objects instead of files.
> HTH,
>
> Paul.
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg
Cheers (and thanks again for the comments),
   Salvatore

-- 
Salvatore Pinto
Cloud Technologist, EGI.eu
e-mail: salvatore.pinto at egi.eu
skype: salvatore.pinto0
Science Park 140, Amsterdam, The Netherlands