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