Call for minor non-distruptive updates to GLUE 2.0
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
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... 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.
Salvatore Pinto [mailto:salvatore.pinto@egi.eu] said:
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.
Somewhere on the web site there should be a list of errata, we should at least incorporate those. It seems to be here: https://redmine.ogf.org/projects/glue-wg/wiki/Errata The EGI GLUE 2 profile defines various OtherInfo attributes. Many of those will be project-specific, but it would be worth reviewing them to see if any seem generic enough to be promoted to real attributes. It's also possible that some of the text comments could usefully be added to the main document, but it would be quite a bit of work to go through them. https://documents.egi.eu/public/ShowDocument?docid=1324
Changes submitted shall be NOT-DISTRUPTIVE and ensure full retro-compatibilty with GLUE 2.0.
In particular any new attributes (or relations) in existing objects must be optional.
#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.
I would suggest that if you want a simple flag it would be better to introduce a new Boolean attribute to indicate whether a service is down, or perhaps an enumeration like up/down/atrisk (or indeed align it with the GOC DB usage). Downtime is logically different to the HealthState, at least as used in EGI - indeed if it weren't the existing "closed" state would be sufficient.
#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.
That's a good idea, but quite a substantial thing in itself! Stephen
Hi all, On 02/09/14 17:45, stephen.burke@stfc.ac.uk wrote:
Somewhere on the web site there should be a list of errata, we should at least incorporate those. It seems to be here:
These seem mostly straight-forward. However, looking at the list I noticed a problem that could ("should"?) be fixed with 2.1. The TrustedCA description says: "Alternatively this may identify a standard bundle of accepted CAs, e.g. those accredited by the IGTF" There's a couple of problems here: 1. "those accredited by the IGTF" is not a single set: IGTF has several different profiles; SLCS, MICS, IOTA and HLCA. 2. The document doesn't say *how* to describe that it is IGTF, or anything else, for that matter. I suggest we: 1. create a registry where people can add CA bundle along with some canonical name, 2. Get rid of the IGTF example (it doesn't help), 3. Add a comment/link/description of the registry to the description.
The EGI GLUE 2 profile defines various OtherInfo attributes. Many of those will be project-specific, but it would be worth reviewing them to see if any seem generic enough to be promoted to real attributes.
Sounds reasonable. Off the top of my head, the one describing which profiles are supported should go in. Stephen, could you post a list of these OtherInfo or send a link to the EGI profile document (for those of us who don't have it to-hand).
In particular any new attributes (or relations) in existing objects must be optional.
Agreed.
#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.
I would suggest that if you want a simple flag it would be better to introduce a new Boolean attribute to indicate whether a service is down, or perhaps an enumeration like up/down/atrisk (or indeed align it with the GOC DB usage). Downtime is logically different to the HealthState, at least as used in EGI - indeed if it weren't the existing "closed" state would be sufficient.
Don't we already support advertising downtime? Endpoint already has DowntimeStart and DowntimeEnd. If we want to be consistent with GOCDB, we could add "at risk" properties, similar to the current downtime properties. HTH, Paul.
Hi, Just addressing this part:
On Sep 8, 2014, at 2:13 PM, Paul Millar <paul.millar@desy.de> wrote:
I suggest we:
1. create a registry where people can add CA bundle along with some canonical name,
This type of registry, if created, would be meaningless without secure links to the CA bundles and an accompanying description of policy for each. This in fact is what the IGTF provides for each of its published bundles. TACAR maintains a list of individual CAs along with secure links to download their individual CA trust anchor files, but only for a subset of academic CAs. I suggest generic language that refers to both as examples. Alan
Paul Millar [mailto:paul.millar@desy.de] said:
I suggest we:
1. create a registry where people can add CA bundle along with some canonical name,
I would suggest treating it like an enumerated type. There should be no problem distinguishing between such names and explicit DNs since the latter will start with a "/".
Stephen, could you post a list of these OtherInfo or send a link to the EGI profile document (for those of us who don't have it to-hand).
Err, the link was in the mail you replied to! https://documents.egi.eu/public/ShowDocument?docid=1324
Don't we already support advertising downtime? Endpoint already has DowntimeStart and DowntimeEnd.
I assume the argument is that it's clumsy to work out how that relates to the current time, and it would be simpler to have a flag. Stephen -- Scanned by iCritical.
Hi Stephen, On 08/09/14 15:28, stephen.burke@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
1. create a registry where people can add CA bundle along with some canonical name,
I would suggest treating it like an enumerated type.
That sounds good. As Alan says, we should include links to descriptions of the CA bundles in that enumeration.
Stephen, could you post a list of these OtherInfo or send a link to the EGI profile document (for those of us who don't have it to-hand).
Err, the link was in the mail you replied to!
[whoops! thanks] As I said, my vote would be for a "Profile" attribute, but I would like it to combined the EGI ProfileName and ProfileVersion into a single attribute. One way of doing this would be to combine the two values with a dash (e.g., OtherInfo: ProfileName=EGI, OtherInfo: ProfileVersion=1.0 becomes Profile=EGI-1.0). This would allow an info-provider to publish support for multiple profiles; e.g.: Profile=EGI-0.5 Profile=EGI-1.0 Profile=NorduNET Profile=XSEDE-basic (Yes, I know, I've said this before.)
Don't we already support advertising downtime? Endpoint already has DowntimeStart and DowntimeEnd.
I assume the argument is that it's clumsy to work out how that relates to the current time, and it would be simpler to have a flag.
True: requiring clock synchronisation isn't great. Also, it seems nobody is really using the Downtime* attributes; at least, not when I checked (perhaps nobody was in down-time just then!). Currently, StoRM publishes: GLUE2EndpointDowntimeAnnounce: No and many gLite services publish a place-holder statement: GLUE2EndpointDowntimeInfo: See the GOC DB for downtimes: https://goc.egi.eu/ So, it might be worth gaining some experience before adding a new attribute. Perhaps this could be added to the EGI profile as an OtherInfo value? Cheers, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
As I said, my vote would be for a "Profile" attribute, but I would like it to combined the EGI ProfileName and ProfileVersion into a single attribute. One way of doing this would be to combine the two values with a dash (e.g., OtherInfo: ProfileName=EGI, OtherInfo: ProfileVersion=1.0 becomes Profile=EGI-1.0).
In general we try to avoid having multiple pieces of formatted information in a single attribute - the main case so far is InterfaceExtension where we have yet to find a way to define or use it! Also I'm doubtful if it means anything to support multiple profiles given that in general they will have conflicts. You could perhaps have a ProfileExtension attribute ...
(Yes, I know, I've said this before.)
The arguments are perhaps slightly different - part of my case was that the EGI profile doesn't need to define attributes relating to other profiles, but that wouldn't apply to the schema itself.
True: requiring clock synchronisation isn't great. Also, it seems nobody is really using the Downtime* attributes; at least, not when I checked (perhaps nobody was in down-time just then!).
In EGI the current situation is that downtimes are managed by the GOC DB - but of course that has now adopted GLUE 2 as an information model so it would be good to bring things in line, whatever we do in the BDII. As things stand there is no easy way to import GOC DB information into the BDII information providers - potentially you could have some kind of unified interface but it seems unlikely that it will happen in practice (the work on the LCG registry was terminated due to lack of interest). In any case the situation with the cloud may be different - managing downtimes for transient services via the GOC DB, which requires static registration, may not be possible. On the other hand, do transient services even have a concept of downtime? Stephen -- Scanned by iCritical.
Hi Stephen, On 08/09/14 17:36, stephen.burke@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
As I said, my vote would be for a "Profile" attribute, but I would like it to combined the EGI ProfileName and ProfileVersion into a single attribute. One way of doing this would be to combine the two values with a dash (e.g., OtherInfo: ProfileName=EGI, OtherInfo: ProfileVersion=1.0 becomes Profile=EGI-1.0).
In general we try to avoid having multiple pieces of formatted information in a single attribute - the main case so far is InterfaceExtension where we have yet to find a way to define or use it!
It kinda depends whether or not you consider "EGI-1.0" a formatted piece of information; it could be an opaque identifier, like "NorduNET" in my examples.
Also I'm doubtful if it means anything to support multiple profiles given that in general they will have conflicts.
Yes, that could be a problem; but it could also be that XSEDE, EGI, OSG (three names chosen at random) could have sufficiently large overlap in their profiles that a service could publish information that is good for all three profiles. AFAIK, currently there is only the EGI profile, so we're speculating here.
You could perhaps have a ProfileExtension attribute ...
What semantics would that have? [...]
True: requiring clock synchronisation isn't great. Also, it seems nobody is really using the Downtime* attributes; at least, not when I checked (perhaps nobody was in down-time just then!).
In EGI the current situation is that downtimes are managed by the GOC DB - but of course that has now adopted GLUE 2 as an information model so it would be good to bring things in line, whatever we do in the BDII. As things stand there is no easy way to import GOC DB information into the BDII information providers - potentially you could have some kind of unified interface but it seems unlikely that it will happen in practice (the work on the LCG registry was terminated due to lack of interest).
Could GOCDB itself inject the information? That would need the concept of an info-modifier: an info-provider that modifies information published by some other info-provider. That concept would be useful elsewhere; e.g., UserDomain and VOMS servers.
In any case the situation with the cloud may be different - managing downtimes for transient services via the GOC DB, which requires static registration, may not be possible. On the other hand, do transient services even have a concept of downtime?
Who can say? But I think "transient" is in the eye of the beholder: with cloud, services could be up for months, if not years. Or the downtime could be that of the cloud-provider itself, much like a CE registering downtime for an upgrade. HTH, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
It kinda depends whether or not you consider "EGI-1.0" a formatted piece of information; it could be an opaque identifier, like "NorduNET" in my examples.
It's only unformatted if you regarded each version of a profile as a completely new specification, and that's unlikely to be the case in general (cf discussions about GLUE 1/GLUE 2/GLUE 2.1).
Yes, that could be a problem; but it could also be that XSEDE, EGI, OSG (three names chosen at random) could have sufficiently large overlap in their profiles that a service could publish information that is good for all three profiles.
Even if it were the case it could be quite difficult to be sure, and might change if any of them had a new version.
You could perhaps have a ProfileExtension attribute ...
What semantics would that have?
As for the InterfaceExtension, it would apply to the case where one profile explicitly included/extended another. For example, potentially we could have that with clouds, i.e. there could be an EGI cloud profile as an extension to the existing one.
Could GOCDB itself inject the information?
Not in the current architecture. The historical development for the BDII and GOC DB was completely different and the information models were also different, so they don't really interact at all. If we still had any middleware development we might well be trying to get them to converge, but as it stands I don't see anything happening.
In any case the situation with the cloud may be different - managing downtimes for transient services via the GOC DB, which requires static registration, may not be possible. On the other hand, do transient services even have a concept of downtime?
Who can say?
Salvatore, perhaps! Stephen -- Scanned by iCritical.
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@egi.eu] Sent: 02 September 2014 09:35 To: GLUE WG (glue-wg@ogf.org) Cc: Peter Solagna; salvatore.pinto@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.
participants (5)
-
david.meredith＠stfc.ac.uk -
Paul Millar -
Salvatore Pinto -
Sill, Alan -
stephen.burke＠stfc.ac.uk