Mailing List Discussions: Comment #3c
Laura F McGinnis wrote:
3c) Section 3.18: ProjectName fits well in Grid projects like LHC and EGEE, but not in terms of virtual organisations which form a natural grouping. We recommend an additional field called "VirtualOrganisation" or "VO".
Evaluation: Defer discussion to mailing list
My main objection to a VirtualOrganization name field is figuring out how to make that have even the slightest chance of being interoperable. Should it be a string (if so, what is in the string), a URL (pointing to what), a complex type (containing what) or ...? Donal.
I think that the area covered by the user identification requires some more thought. A UR needs to allow the recording of (at least?) two different things: 1) Who has paid/will pay for the resources consumed 2) Under whose authority the job was run These may not be the same entity. The fields could be complex e.g. user -> project -> VO or but may also need to represent a chain of delegation or local account used or ... How much is needed in a UR? How much should be delegated to delegated to the original authorities for this information? On 4 May 2006, at 22:17, Donal K. Fellows wrote:
Laura F McGinnis wrote:
3c) Section 3.18: ProjectName fits well in Grid projects like LHC and EGEE, but not in terms of virtual organisations which form a natural grouping. We recommend an additional field called "VirtualOrganisation" or "VO".
Evaluation: Defer discussion to mailing list
My main objection to a VirtualOrganization name field is figuring out how to make that have even the slightest chance of being interoperable. Should it be a string (if so, what is in the string), a URL (pointing to what), a complex type (containing what) or ...?
Donal.
Sven Sven.vandenBerghe@uk.fujitsu.com Fujitsu Laboratories of Europe +44 208 606 4651
Donal K. Fellows wrote:
Laura F McGinnis wrote:
3c) Section 3.18: ProjectName fits well in Grid projects like LHC and EGEE, but not in terms of virtual organisations which form a natural grouping. We recommend an additional field called "VirtualOrganisation" or "VO".
Evaluation: Defer discussion to mailing list
My main objection to a VirtualOrganization name field is figuring out how to make that have even the slightest chance of being interoperable. Should it be a string (if so, what is in the string), a URL (pointing to what), a complex type (containing what) or ...?
Donal.
To clarify what the field contains, it might also be called "VOName", being just a plain string. However, a field that determines the name of the VO is needed, at least for LCG/EGEE and I'm sure other grid projects/enviroments will appreciate it, too. A better idea would eventually be having an element "VO" or "VirtualOrganization" that in turn contains an element or attribute "VOName". this would allow for later extension in case somebody needs an URL or whatever ... Cheers, Rosario. -- ------------------------------------- Rosario Piro (piro@to.infn.it) http://www.to.infn.it/~piro/ ------------------------------------- Istituto Nazionale di Fisica Nucleare Sezione di Torino ------------------------------------- National Insitute for Nuclear Physics Section of Turin, Italy -------------------------------------
Rosario Michael Piro wrote:
To clarify what the field contains, it might also be called "VOName", being just a plain string. However, a field that determines the name of the VO is needed, at least for LCG/EGEE and I'm sure other grid projects/enviroments will appreciate it, too.
A better idea would eventually be having an element "VO" or "VirtualOrganization" that in turn contains an element or attribute "VOName". this would allow for later extension in case somebody needs an URL or whatever ...
I'm not 100% convinced. But then I've never really understood what a VO Name is to start out with. Mind you, I don't feel all that much happier about the whole notion of VO; I suspect that it's overloaded with all sorts of stuff that perhaps ought to be described in different ways. I can't quite put my finger on what's making me feel like this though. Oh well... :-( Donal.
Donal K. Fellows wrote:
Rosario Michael Piro wrote:
To clarify what the field contains, it might also be called "VOName", being just a plain string. However, a field that determines the name of the VO is needed, at least for LCG/EGEE and I'm sure other grid projects/enviroments will appreciate it, too.
A better idea would eventually be having an element "VO" or "VirtualOrganization" that in turn contains an element or attribute "VOName". this would allow for later extension in case somebody needs an URL or whatever ...
I'm not 100% convinced. But then I've never really understood what a VO Name is to start out with. Mind you, I don't feel all that much happier about the whole notion of VO; I suspect that it's overloaded with all sorts of stuff that perhaps ought to be described in different ways.
I can't quite put my finger on what's making me feel like this though. Oh well... :-(
Well, it might be overloaded, but it is heavily used, at least in the HEP community. If we don't define in the UR standard, then I'm sure most grid projects/communities will add an extension since they require it. The risk is, of course, to end up with several customized extensions that make interoperability difficult, and this is excatly what a standard should prevent from. Regarding LCG, for example, the single VOs (that correspond to the LHC experiments) want an accounting that is perfetly able to distinguish between jobs from different VOs (one use can be subscribed to different VOs and thus the accounting system requires information on the VO for which a user sublitted a given job, not only because of funding issues between VOs and institutes that provide the resources). They go even further and want to have accounting per group and role, to distinguish between jobs executed for production purpose or data analysis, job submitted by admins, etc. The group and role for which a job has been submitted is contained in the UserFQAN of the VOMS proxy certificate that has been used for submission (something like, for example, "/atlas/production/Role=...", where atlas is the VO, production the group, etc.) Generally, I would say, that the identity of a user is far more than just his DN (Name). The identity of a user depends also on his role within an institute or VO. I have seen user DNs that were subscribed to even four or more VOs; I myself belong to several VOs. Who "pays" for my jobs if the accounting system isn't able to distinguish between jobs submitted on behalf of one VO or the other? And what if some VOs can execute jobs for free on a given resource while others have to pay? Those are realistic use cases that require accounting records to contain information about the user's VO. And I would even add the userFQAN to the UR, because you might also want to apply different prices based on wether a user is an admin or a student, wether he/she does production or analysis, etc. Cheers, Rosario.
Donal.
-- ------------------------------------- Rosario Piro (piro@to.infn.it) http://www.to.infn.it/~piro/ ------------------------------------- Istituto Nazionale di Fisica Nucleare Sezione di Torino ------------------------------------- National Insitute for Nuclear Physics Section of Turin, Italy -------------------------------------
participants (4)
-
Donal K. Fellows -
Laura F McGinnis -
Rosario Michael Piro -
Sven van den Berghe