[glue-wg] Call for minor non-distruptive updates to GLUE 2.0

Salvatore Pinto salvatore.pinto at egi.eu
Tue Sep 2 04:35:18 EDT 2014


 Dear GLUErs,
since we are going to revision GLUE 2.0 to GLUE 2.1, I would like to ask
the mailing list to point me to some changes which, in your opinion, should
be incorporated in this revision. I will collect these changes and then
organize a discussion for the GLUE WG meetings.

Changes submitted shall be NOT-DISTRUPTIVE and ensure full
retro-compatibilty with GLUE 2.0. Example of such changes may be fixing of
typos, making description of attributes more clear (without changing the
attribute meaning), updating enumerations by adding new fields, etc...

>From my side, beside, of course, the addition of the cloud entities, I
would like to propose:
 #1. Put a link to the Open Enumerations procedure. I propose to add a
short text with the link in appendix B (Data types), explaining that,
before defining a new enumerations, it is recommended to apply the Open
Enumerations best practices.
 #2. Fix the broken link to VOMS website ( http://voms.forge.cnaf.infn.it/).
I propose to replace it with the WikiPedia link (
http://en.wikipedia.org/wiki/VOMS),  which is the closest one to a
"persistent identifier" I can find, or remove it entirely.
 #3. Add to EndpointHealthState_t (closed enumeration) a state named
"downtime", this would be much simpler to signal current downtime status to
the users or cloud brokers than via the DowntimeStart/End times.
 #4. Add GPU resources to the Execution Environment. This can be important
for the EGI-ENGAGE and other sister projects in H2020, were we are planning
to integrate GPGPU computing in both Cloud and Grid.
 #5. Add to the StorageShare a Maximum and Minimum object (file) size
allowed. THis would be of interest in the cloud, there the object stored
can be for example an additional virtual disk which size can be restricted
between given boundaries (eg. for most of the EGI FedCloud sites from 1GB
to 100GB).
 #6. For the storage elements descriptions, replace the word "file" with
"data object". The idea is that the storage service may support multiple
data objects types (eg. files, images, documents, etc...). The kind of
objects supported will be included the service capabilities.

Cheers,
  Salvatore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20140902/d20349be/attachment.html>


More information about the glue-wg mailing list