[glue-wg] Extending GLUE 2.0 for Cloud services

Wed Dec 4 11:11:23 EST 2013

> In other words, as long as the core model doesn't change significantly, we
> increment within the 2.x series.

Ok. 

> > Rather, as was originally intended, shouldn't the cloud specialisations
> extend the existing abstract base-types and add extra attributes, types,
> enums etc as required by those specialisations?
> 
> I thought that was what we agreed to in our last teleconference: we would
> not abstract the Compute specializations but rather add new Cloud
> specializations.

Good - I must have missed that. This was my biggest concern. 

> The existing model document describes current specializations, why should
> cloud specializations be treated differently and put in a separate document?

Fair enough. 

> JP
> 
> > cheers,
> > David
> >
> > --------------------------------------------------------------
> > David Meredith
> > STFC eScience Centre
> > Daresbury Laboratory (A32)
> > Warrington, Cheshire
> > WA4 4AD
> >
> > email: david.meredith at stfc.ac.uk
> > tel: +44 (0)1925 603762
> >
> > ________________________________________
> > From: glue-wg-bounces at ogf.org [glue-wg-bounces at ogf.org] on behalf of
> > Warren Smith [wsmith at tacc.utexas.edu]
> > Sent: 03 December 2013 14:18
> > To: Salvatore Pinto; Paul Millar
> > Cc: glue-wg at ogf.org; Peter Solagna
> > Subject: Re: [glue-wg] Extending GLUE 2.0 for Cloud services
> >
> > 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
> > _______________________________________________
> > glue-wg mailing list
> > glue-wg at ogf.org
> > https://www.ogf.org/mailman/listinfo/glue-wg
> > --
> > Scanned by iCritical.
> > _______________________________________________
> > glue-wg mailing list
> > glue-wg at ogf.org
> > https://www.ogf.org/mailman/listinfo/glue-wg

-- 
Scanned by iCritical.