Handling VO specific information in Glue 2.1
Hi *, as we start to implement v2.1 of the GlueSchema for the EGI federated cloud we have realised that we miss some VO specific information and we are unsure how/where is the best way to publish this: Users belong to several VOs and sites may support more than one of those. When users authenticate against a given endpoint, the endpoint will return a list of local projects/groups that the users is allowed to use. Each project/group supports a VO in our current implementation. While in the past this was not an issue since the user authenticated with a VOMS proxy that only contained information a single VO and therefore the endpoint would just return a single project. Now with the transition to federated identity, the endpoint will receive claims on every VO the user is member of and there is no way for the user to determine which local project/group to use. We would need a way to publish a site-defined identifier of the project/group that supports each VO at a given site, so user could just match the VO with that id and select the appropriate one during authentication. We have checked the current draft of the schema and haven't seen a clear place to publish this kind of information. Our current guess would be to include this in the AccessPolicy or MappingPolicy. Since in our implementation we are using shares as a way to express VO information probably for us the MappingPolicy is the best fit, but would like to get your input on the best way to proceed. PS: I tried to submit this email before being subscribed, so apologies if it gets sent twice.
-- Enol Fernández | Cloud Technologist | EGI Foundation enol.fernandez@egi.eu
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Enol Fernández said:
Since in our implementation we are using shares as a way to express VO information probably for us the MappingPolicy is the best fit, but would like to get your input on the best way to proceed.
Generally that kind of thing would go in the Share, for example StorageShare has a Path attribute to publish which part of the storage namespace belongs to each VO. Stephen
On 18 October 2017 at 15:05, <stephen.burke@stfc.ac.uk> wrote:
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Enol Fernández said:
Since in our implementation we are using shares as a way to express VO information probably for us the MappingPolicy is the best fit, but would like to get your input on the best way to proceed.
Generally that kind of thing would go in the Share, for example StorageShare has a Path attribute to publish which part of the storage namespace belongs to each VO.
That would imply that a share is to be accessed by a single VO, is that correct? Enol
Stephen
-- Enol Fernández | Cloud Technologist | EGI Foundation enol.fernandez@egi.eu
Enol Fernández [mailto:enol.fernandez@egi.eu] said:
That would imply that a share is to be accessed by a single VO, is that correct?
It depends how you use it, the schema itself isn't prescriptive. In general a Share provides information about some part of a Resource which is usable by some group of users, but a given application needs to decide what constitutes a suitable group. Stephen
Hi all, sorry for not having replied before, but many emails to this list are put in the spam folder: google filters are very aggressive! In our GLUE2.1 implementation, there is one Share per VO, so we can add here the new attribute for the identifier of that particular VO. Cheers, Alessandro On 18 October 2017 at 18:48, <stephen.burke@stfc.ac.uk> wrote:
Enol Fernández [mailto:enol.fernandez@egi.eu] said:
That would imply that a share is to be accessed by a single VO, is that correct?
It depends how you use it, the schema itself isn't prescriptive. In general a Share provides information about some part of a Resource which is usable by some group of users, but a given application needs to decide what constitutes a suitable group.
Stephen
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
Hi all The current implementation of VO stuff for Computing element is done using the AccessPolicy and MappingPolicy objects with basic policy and rules as defined in GFD147. Having a new attribute in my opinion is dreadful as it might generate inconsistencies between these two approaches. On the other hand an attribute will make searches more efficient, as one just needs to query for that attribute to retrieve the share objects, while in Computing now one has to fetch all shares and their siblings first, process the mapping policies for each share and then identify those that are related to the VO's MappingPolicy. The way Stephen suggests I never liked, doing regular expressions on strings that are not related to concepts in the model it is very annoying. One can decide that a namespace contains whatever information one wants, also the age of the person who wrote the last file, but I think digging out information this way is a sad way to go and makes the use of a schema questionable. But I don't do storage so I won't stress this. Querying the lcg bdii (lcg-bdii.cern.ch) for Mapping/Access Policies and Shares will show you how it is done in the computing part, I guess you're probably already aware of it. I think we make it more complicated and cumbersome by having a completely different approach on cloud storage. Cheers, Florido On 2017-10-19 10:20, Alessandro Paolini wrote:
Hi all,
sorry for not having replied before, but many emails to this list are put in the spam folder: google filters are very aggressive!
In our GLUE2.1 implementation, there is one Share per VO, so we can add here the new attribute for the identifier of that particular VO.
Cheers, Alessandro
On 18 October 2017 at 18:48, <stephen.burke@stfc.ac.uk <mailto:stephen.burke@stfc.ac.uk>> wrote:
Enol Fernández [mailto:enol.fernandez@egi.eu <mailto:enol.fernandez@egi.eu>] said: > That would imply that a share is to be accessed by a single VO, is that correct?
It depends how you use it, the schema itself isn't prescriptive. In general a Share provides information about some part of a Resource which is usable by some group of users, but a given application needs to decide what constitutes a suitable group.
Stephen
_______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> https://www.ogf.org/mailman/listinfo/glue-wg <https://www.ogf.org/mailman/listinfo/glue-wg>
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus A, Rum A403 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
Hi Florido, thanks for your comments. The idea is to add a new attribute into the CloudComputingShare class, since for the moment it seems the more appropriate place for that identifier (we are not talking about cloud storage). cheers, Alessandro On 19 October 2017 at 15:07, Florido Paganelli <florido.paganelli@hep.lu.se> wrote:
Hi all
The current implementation of VO stuff for Computing element is done using the AccessPolicy and MappingPolicy objects with basic policy and rules as defined in GFD147. Having a new attribute in my opinion is dreadful as it might generate inconsistencies between these two approaches. On the other hand an attribute will make searches more efficient, as one just needs to query for that attribute to retrieve the share objects, while in Computing now one has to fetch all shares and their siblings first, process the mapping policies for each share and then identify those that are related to the VO's MappingPolicy.
The way Stephen suggests I never liked, doing regular expressions on strings that are not related to concepts in the model it is very annoying. One can decide that a namespace contains whatever information one wants, also the age of the person who wrote the last file, but I think digging out information this way is a sad way to go and makes the use of a schema questionable. But I don't do storage so I won't stress this.
Querying the lcg bdii (lcg-bdii.cern.ch) for Mapping/Access Policies and Shares will show you how it is done in the computing part, I guess you're probably already aware of it.
I think we make it more complicated and cumbersome by having a completely different approach on cloud storage.
Cheers, Florido
On 2017-10-19 10:20, Alessandro Paolini wrote:
Hi all,
sorry for not having replied before, but many emails to this list are put in the spam folder: google filters are very aggressive!
In our GLUE2.1 implementation, there is one Share per VO, so we can add here the new attribute for the identifier of that particular VO.
Cheers, Alessandro
On 18 October 2017 at 18:48, <stephen.burke@stfc.ac.uk <mailto: stephen.burke@stfc.ac.uk>> wrote:
Enol Fernández [mailto:enol.fernandez@egi.eu <mailto:enol.fernandez@egi.eu>] said: > That would imply that a share is to be accessed by a single VO, is that correct?
It depends how you use it, the schema itself isn't prescriptive. In general a Share provides information about some part of a Resource which is usable by some group of users, but a given application needs to decide what constitutes a suitable group.
Stephen
_______________________________________________ glue-wg mailing list glue-wg@ogf.org <mailto:glue-wg@ogf.org> https://www.ogf.org/mailman/listinfo/glue-wg <https://www.ogf.org/mailman/listinfo/glue-wg>
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus A, Rum A403 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
participants (4)
-
Alessandro Paolini -
Enol Fernández -
Florido Paganelli -
stephen.burke＠stfc.ac.uk