[glue-wg] modelling users

Timo Baur Timo.Baur at lrz-muenchen.de
Mon Apr 14 15:14:31 CDT 2008


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 at ogf.org 
>>   
>>     
>>> [mailto:glue-wg-bounces at 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 at ogf.org
>> http://www.ogf.org/mailman/listinfo/glue-wg
>>   
>>     
>
> _______________________________________________
> glue-wg mailing list
> glue-wg at 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 at lrz-muenchen.de




More information about the glue-wg mailing list