[glue-wg] Extending GLUE 2.0 for Cloud services

[Warren Smith]

I expect to be on the call in a bit, but I thought I'd send a note that I haven't had any problem representing OpenStack and Nimbus IaaS clouds in the existing GLUE2 model. So far, I've primarily focused on the compute side, but I thought it was as straightforward to map GLUE2 entities to IaaS concepts as it was to map GLUE2 entities to cluster concepts.

I haven't done too much with the storage entities, but so far, it seems to me like the mapping to existing GLUE2 doesn't seem that much more difficult than for clusters...


A final thought is if we want to open the GLUE 2 model for changes, I'll have some suggestions based on my experiences so far. However, I don't feel a huge need to open the model for changes right now.


Warren



> -----Original Message-----
> From: glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
> Behalf Of Salvatore Pinto
> Sent: Tuesday, December 03, 2013 2:30 AM
> To: Paul Millar
> Cc: glue-wg at ogf.org; Peter Solagna
> Subject: Re: [glue-wg] Extending GLUE 2.0 for Cloud services
> 
> Hi Paul,
> sorry for the late answers.
> 
> On 05/11/2013 19:09, Paul Millar wrote:
> > Hi Salvatore,
> >
> > I think your work is very interesting: GLUE-2 is trying to be
> > extensible and technology agnostic.  Trying to describe cloud
> services
> > as GLUE-2 objects is an excellent test of how well we've achieved
> that
> > goal.
> >
> > Some further replies, in-line:
> >
> > On 05/11/13 10:05, Salvatore Pinto wrote:
> >> 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.
> >
> > If there are attributes that are mandatory which make no sense in
> > other kinds of services then we should certainly consider relaxing
> > those requirements.
> >
> > Relationships between objects should also be expressible as
> extensions
> > without requiring schema changes.  If this isn't the case (for
> > whatever reason) then that, too, is something that should be fixed.
> >
> ok, I did not thought about the possibility to define new relationships
> as extensions, I thought the option was only for attributes. Anyway,
> there are other reasons to create new entities. We can discuss about
> that at the conference today.
> >
> >> 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.
> >
> > This, I think, is the point which I really disagree with.
> >
> > Let me give you a concrete example.
> >
> > We (dCache.org) have just started running a dCache instance that is
> > very much a cloud storage service.  Client software (of which there
> > are various) currently accessed it via WebDAV, but we anticipate
> > adding support for CDMI.  We want to make this storage (or a similar
> > cloud service) available to grid users in the future.
> >
> > IMHO, we *will* have storage systems that provide cloud-like and
> > grid-like services; it would be a good idea not to exclude this from
> > the start.
> >
> > [...]
> for storage, I agree, for Computing, I do not. We can discuss about
> that in today's teleconference.
> >> 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).
> >
> > Sorry, I didn't explain myself clearly; what you're describing is the
> > CDMI concept of metadata (as per Chapter 16).  I meant the more
> > general metadata: "data about something".
> >
> > The CDMI protocol also supports a client discovering information
> about
> > the service itself; the main motivation is to allow the client to
> > discover if a service is appropriate for its needs. This matches one
> > of the core uses of GLUE-2: to select an appropriate storage services
> > without querying each service individually.
> >
> > For examples of this, see section 6.2 "Discovering the Capabilities
> of
> > a Cloud Storage" and section 12.2 "Cloud Storage System-Wide
> > Capabilities".
> >
> > The "Exported Protocols" (see Section 13) is broadly similar to the
> > concept of StorageEndpoints or StorageAccessProtocol in GLUE-2, so
> > this would also be an interesting avenue for mapping.
> >
> > There's also explicit support in CDMI for representing links to OCCI
> > services.  This holds a similar role to the ToComputingService
> objects
> > in GLUE-2.
> >
> > (you see how these two worlds are not really *that* different)
> >
> >
> >> again, one point for modifying the original Storage elements to
> >> consider objects instead of files.
> >
> > IMHO this isn't a good reason.
> >
> > In most cases "objects" ("data-objects" in CDMI) are really just a
> > synonym for files and a "buckets" ("container" in CDMI) is a synonym
> > for a directory.
> >
> no, I do not agree. Block storage is widely used in the Cloud today and
> a disk image (which is mounted by the hypervisor and exposed as an
> "Hardware" storage disk resource) it is quite a different concept from
> a container or a file. The fact that currently almost all the CDMI
> implementations support only file objects, it is another point and
> should not be a concern of the GLUE, since implementations and
> interface technology may change in the future. The important point, in
> my view, is that users will be misleaded if they see "files" in the
> specification.
> > Sure, in S3, there are some limitations on the interactions, that's
> an
> > implementation-specific detail.  If those limitations are important
> to
> > clients then we can describe them (as per CDMI).
> >
> > Whether GLUE-2 talks about 'files' or 'objects' (or Feile, Fichier or
> > ファイル) really doesn't matter if the underlying concept is the same.
> >
> > HTH,
> >
> > Paul.
> 
> Cheers,
>    Salvatore.
> 
> --
> Salvatore Pinto
> Cloud Technologist, EGI.eu
> e-mail: salvatore.pinto at egi.eu
> skype: salvatore.pinto0
> Science Park 140, Amsterdam, The Netherlands
> 
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg