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

[david.meredith at stfc.ac.uk]

Hi Salvatore,
I’ve not had a chance to go through all the proposed changes in detail yet, but after an initial glance it would appear some changes are not backward compatible. For example, changes to the existing v2 closed types cause issues, e.g. the closed ‘EndpointHealthState_t’ would need updating in the existing XSD to introduce the new ‘downtime’ enum value:

<simpleType name="EndpointHealthState_t">
<restriction base="string">
<enumeration value="critical"/>
<enumeration value="ok"/>
<enumeration value="other"/>
<enumeration value="unknown"/>
<enumeration value="warning"/>
</restriction>
</simpleType>

(https://github.com/OGF-GLUE/XSD/blob/master/glue2.xsd)

If there are more changes to the existing v2 entities/types, I imagine it may become necessary to also publish a new/updated 2.1 XSD rendering also (I’d prefer not to have to do this if possible, but realize it may turn out to be needed in practice). Something for discussion I guess.

Thanks,
David


From: Salvatore Pinto [mailto:salvatore.pinto at egi.eu]
Sent: 02 September 2014 09:35
To: GLUE WG (glue-wg at ogf.org)
Cc: Peter Solagna; salvatore.pinto at esa.int
Subject: [glue-wg] Call for minor non-distruptive updates to GLUE 2.0

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.

This would break the existing glue2 EndpointHealthState_t in the XSD:



 #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/6ed1f59d/attachment.html>