[glue-wg] Extending GLUE 2.0 for Cloud services

[Salvatore Pinto]

Hi Andre,

On 05/11/2013 14:08, Andre Merzky wrote:
>
> On Tue, Nov 5, 2013 at 1:49 PM, Salvatore Pinto 
> <salvatore.pinto at egi.eu <mailto:salvatore.pinto at egi.eu>> wrote:
>
>     Hi Stephen,
>     yes, replacing "files" with "data object" in the text it is fine,
>     but, in my opinion, we should also perform the following changes:
>
>     * Add to StorageEndpoint element the following attribute:
>
>     SupportedObjects
>
>     	
>
>     CloudStorageT_t
>
>     	
>
>     *
>
>     	
>
>     	
>
>     Supported data object formats (ex. Image disks, files, generic
>     objects, etc…)
>
>     . For the use is important to know which kind of storage the
>     service provides, if it is storage for files, disk images, EBS
>     attached storage, etc...
>
>
> Why wouldn't tht be 'StorageT_t'?  The same argument can be made for 
> non-cloudy storage resources.
>
yes, of course, StorageT_t, my mistake :)
>
>     * Add to StorageShare the following attributes:
>
>     MaxObjectSize
>
>     	
>
>     UInt64
>
>     	
>
>     0..1
>
>     	
>
>     MB
>
>     	
>
>     Maximum size of a data object who can be stored in this share
>
>     MinObjectSize
>
>     	
>
>     UInt64
>
>     	
>
>     0..1
>
>     	
>
>     MB
>
>     	
>
>     Minimum size of a data object who can be stored in this share
>
>     This is very important for the user (especially for EBS storage,
>     where the storage object is a disk attached to a VM) to choose
>     which storage service is better for their need and for the
>     authomatic systems to perform auto-scaling of the storage.
>
>
> Are there systems where MinObjSize is *not* zero?
>
yes, for example Amazon EBS (storage volumes attached to the VMs) 
supports sizes from 1GB to 1TB . Actually, the objects size may also be 
not even a continuous number, for example Interoute EBS allows only 
250GB, 500GB, 1TB, 1.5 TB and 2TB.

> My $0.02,
>
>   Andre.
Cheers,
   Salvatore.
>
>
>     Of course, we could use the extensions to add these attributes and
>     do not change the standard...
>
>     Regarding the capabilities for the storage taken from CDMI or
>     other cloud standards (ex. support for file encryption, single
>     file ACLs, etc...), they may go into the Capability attribute of
>     the StorageEndpoint, which is an open enumeration, so we need to
>     add nothing for that.
>
>     Cheers,
>       Salvatore.
>
>
>     On 05/11/2013 11:59, stephen.burke at stfc.ac.uk
>     <mailto:stephen.burke at stfc.ac.uk> wrote:
>>     glue-wg-bounces at ogf.org  <mailto:glue-wg-bounces at ogf.org>  [mailto:glue-wg-bounces at ogf.org] On
>>>     Behalf Of Salvatore Pinto said:
>>>     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?
>>     I don't think the  current schema really represents files - the word "file" may appear in the text but you could replace it with "data object" without changing anything. It isn't feasible to publish information about individual files, all we have is summary information about larger blocks of storage. Also storage systems presumably don't have the biggest difference between cloud and grid computing services, namely that they aren't persistent and can be created and destroyed - storage has to be persistent to be useful!
>>
>>>     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.
>>     You certainly wouldn't want to publish the state of individual files, but you may want to advertise the capability to do various things, similarly to the support for different access protocols.
>>
>>     Stephen
>>
>
>
>     -- 
>     Salvatore Pinto
>     Cloud Technologist, EGI.eu
>     e-mail:salvatore.pinto at egi.eu  <mailto:salvatore.pinto at egi.eu>
>     skype: salvatore.pinto0 Science Park 140, Amsterdam, The Netherlands
>
>
>     _______________________________________________
>     glue-wg mailing list
>     glue-wg at ogf.org <mailto:glue-wg at ogf.org>
>     https://www.ogf.org/mailman/listinfo/glue-wg
>
>
>
>
> -- 
> Nothing is really difficult.


-- 
Salvatore Pinto
Cloud Technologist, EGI.eu
e-mail: salvatore.pinto at egi.eu
skype: salvatore.pinto0
Science Park 140, Amsterdam, The Netherlands

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20131105/b29cafd4/attachment-0001.html>