[glue-wg] Extending GLUE 2.0 for Cloud services

Wed Dec 4 01:44:49 EST 2013

hi folks, 
Regarding the cloud entity sub-type specialisations: 

I'm with Warren in that I don't think the conceptual model should be incremented (2.1) unless there are strong and compelling reasons to change the core model and introduce structural updates.  

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? 

These newly derived (cloud) types should then be presented in a separate extension doc that does not need to repeat the existing model, but instead describes how the new dervied types extend and supplement the base model. 

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.