On Dec 4, 2013, at 12:44 AM, <david.meredith@stfc.ac.uk> <david.meredith@stfc.ac.uk> wrote:
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.
Given that we have a 2.0 version of the _document_ that describes the conceptual model, are you suggesting a more minor version increment? Perhaps 2.0.1? My view, which may not match how others see things, is that two version numbers is all we need, and incremental numbers within the 2.x series simply signify sequential document version and do not indicate the significance of the changes between each version. Significant and possibly incompatible changes would produce 3.0. In other words, as long as the core model doesn't change significantly, we increment within the 2.x series.
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.
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.
The existing model document describes current specializations, why should cloud specializations be treated differently and put in a separate document? JP
cheers, David
-------------------------------------------------------------- David Meredith STFC eScience Centre Daresbury Laboratory (A32) Warrington, Cheshire WA4 4AD
email: david.meredith@stfc.ac.uk tel: +44 (0)1925 603762
________________________________________ From: glue-wg-bounces@ogf.org [glue-wg-bounces@ogf.org] on behalf of Warren Smith [wsmith@tacc.utexas.edu] Sent: 03 December 2013 14:18 To: Salvatore Pinto; Paul Millar Cc: glue-wg@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@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Salvatore Pinto Sent: Tuesday, December 03, 2013 2:30 AM To: Paul Millar Cc: glue-wg@ogf.org; Peter Solagna Subject: Re: [glue-wg] Extending GLUE 2.0 for Cloud services
Hi Paul, sorry for the late answers.
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
On 05/11/2013 19:09, Paul Millar wrote: 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
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
are 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@egi.eu skype: salvatore.pinto0 Science Park 140, Amsterdam, The Netherlands
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg