Hi list, in order to map running Globus-jobs to VOs, we now try to model user information with GLUE 2.0. From GRAM-Audit, we get (local user id, user DN, job). From another source, we will hopefully get (user DN, user name, VO). Should we best encode the user information in an composed UserDomain like UserDomain (Name: VO) composed by UserDomain(UniqueID: user DN, name: user name) or is there another solution ? Does anybody think it would make sense to introduce an additional or specialized entity for users ? Cheers, Timo -- Dipl-Inf. Timo Baur Leibniz Rechenzentrum Kommunikationsnetze/Netzplanung Boltzmannstr. 1 D-85748 Garching Telefon +49 89 35831-8729 Fax +49 89 35831-5729 timo.baur@lrz-muenchen.de
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Timo Baur said: Does anybody think it would make sense to introduce an additional or specialized entity for users ?
This seems to come into the area of detailed accounting which glue is not supposed to cover. If you try to put user information into the schema it will get very big, and it may also be illegal under data protection law unless access is very restricted. In LCG/EGEE we have a specialised accounting application (APEL) which encrypts user information, but it has still taken a long time to get a legal agreement that allows us to use it, and I think some sites still opt out of providing it. Stephen
Hi Stephen, We are defining an information model but this does not necessarily mean that the whole model is published into the information system. Our currently experience is the mode of operation where everything is in the information system and this is where our experience lies. However, we might need to define some things that help us, for example, we might need an object to help us link to the Usage Record or at lease agree on certain definitions. If there is a clear use case for this to be in the model, we can considered it against all the other priorities. Laurence Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Timo Baur said: Does anybody think it would make sense to introduce an additional or specialized entity for users ?
This seems to come into the area of detailed accounting which glue is not supposed to cover. If you try to put user information into the schema it will get very big, and it may also be illegal under data protection law unless access is very restricted. In LCG/EGEE we have a specialised accounting application (APEL) which encrypts user information, but it has still taken a long time to get a legal agreement that allows us to use it, and I think some sites still opt out of providing it.
Stephen _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi, I tried to express a use case regarding this topic and to handle it with the current status of GLUE. Use Case: Monitor job status for a specific user in a specific VO Note: Extension of Job Monitoring use case (9): Find the current status of a job Description: Enable only VO members to find out the current status of a VOs' jobs Conversation: ability to associate DN with VO Actors: End User (VO member), user- / VO-specific monitoring applications Conversation: Ability to query job information for a given user DN and/or VO ID Acceptance : Show the current status of the jobs for a given user and/or VO Endorsed by: D-Grid Requirements: it is necessary to know (job, VO), (job, DN) and (DN, VO). status-quo: ComputingActivity:LRMSID is managedby UserDomain -> (job, VO) There is a field ComputingActivity:Owner -> (job, DN) ComputingActivity:Owner is managedby UserDomain -> (DN, VO) Thus, in principle, the necessary information and associations to resolve the use case are already available in the schema. Nevertheless, "Owner" is user related information and ComputingActivities usually are managed by their Owner. In my opinion, it should be moved to UserDomain instead of storing it in a ComputingActivity. I propose to move the string "Owner" to UserDomain or a specialization of it. UserDomain:Owner could then, if necessary, be linked to usage records:GlobalUsername, but this would be independent from our use case as this would be related to the accounting of jobs which are already finished, in contrast to the jobs of a VO or user which are actually running. Timo Laurence Field wrote:
Hi Stephen,
We are defining an information model but this does not necessarily mean that the whole model is published into the information system. Our currently experience is the mode of operation where everything is in the information system and this is where our experience lies. However, we might need to define some things that help us, for example, we might need an object to help us link to the Usage Record or at lease agree on certain definitions.
If there is a clear use case for this to be in the model, we can considered it against all the other priorities.
Laurence
Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Timo Baur said: Does anybody think it would make sense to introduce an additional or specialized entity for users ?
This seems to come into the area of detailed accounting which glue is not supposed to cover. If you try to put user information into the schema it will get very big, and it may also be illegal under data protection law unless access is very restricted. In LCG/EGEE we have a specialised accounting application (APEL) which encrypts user information, but it has still taken a long time to get a legal agreement that allows us to use it, and I think some sites still opt out of providing it.
Stephen _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- Dipl-Inf. Timo Baur Leibniz Rechenzentrum Kommunikationsnetze/Netzplanung Boltzmannstr. 1 D-85748 Garching Telefon +49 89 35831-8729 Fax +49 89 35831-5729 timo.baur@lrz-muenchen.de
Hi Timo, The Glue schema should be focusing on service discovery and service meta data. Although there are a few things in the schema related to monitoring, this is for legacy reasons and it is not something that we should encourage. The job monitoring is in the schema due it is important for ARC as they have been working this way for many years. However, this will not be used for EGEE. Like Accounting, Monitoring is something where we need to have agreement if we are to interoperate but at the moment Glue does not aim to cover these things. In the future, it may or other groups will be set up to cover this. What is important is something like the reference model which defines the fundamental entities and the relationships between them do this and that there is coherence between the Accounting, JSDL, Service Discovery etc. I do not think that this use case currently fits in with Glue. Laurence Timo Baur wrote:
Hi,
I tried to express a use case regarding this topic and to handle it with the current status of GLUE.
Use Case: Monitor job status for a specific user in a specific VO
Note: Extension of Job Monitoring use case (9): Find the current status of a job Description: Enable only VO members to find out the current status of a VOs' jobs Conversation: ability to associate DN with VO Actors: End User (VO member), user- / VO-specific monitoring applications Conversation: Ability to query job information for a given user DN and/or VO ID Acceptance : Show the current status of the jobs for a given user and/or VO Endorsed by: D-Grid
Requirements: it is necessary to know (job, VO), (job, DN) and (DN, VO).
status-quo: ComputingActivity:LRMSID is managedby UserDomain -> (job, VO) There is a field ComputingActivity:Owner -> (job, DN) ComputingActivity:Owner is managedby UserDomain -> (DN, VO)
Thus, in principle, the necessary information and associations to resolve the use case are already available in the schema.
Nevertheless, "Owner" is user related information and ComputingActivities usually are managed by their Owner. In my opinion, it should be moved to UserDomain instead of storing it in a ComputingActivity.
I propose to move the string "Owner" to UserDomain or a specialization of it. UserDomain:Owner could then, if necessary, be linked to usage records:GlobalUsername, but this would be independent from our use case as this would be related to the accounting of jobs which are already finished, in contrast to the jobs of a VO or user which are actually running.
Timo
Laurence Field wrote:
Hi Stephen,
We are defining an information model but this does not necessarily mean that the whole model is published into the information system. Our currently experience is the mode of operation where everything is in the information system and this is where our experience lies. However, we might need to define some things that help us, for example, we might need an object to help us link to the Usage Record or at lease agree on certain definitions.
If there is a clear use case for this to be in the model, we can considered it against all the other priorities.
Laurence
Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Timo Baur said: Does anybody think it would make sense to introduce an additional or specialized entity for users ?
This seems to come into the area of detailed accounting which glue is not supposed to cover. If you try to put user information into the schema it will get very big, and it may also be illegal under data protection law unless access is very restricted. In LCG/EGEE we have a specialised accounting application (APEL) which encrypts user information, but it has still taken a long time to get a legal agreement that allows us to use it, and I think some sites still opt out of providing it.
Stephen _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
participants (3)
-
Burke, S (Stephen) -
Laurence Field -
Timo Baur