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@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@egi.eu skype: salvatore.pinto0 Science Park 140, Amsterdam, The Netherlands