[jsdl-wg] Issues for todays phone conference

[Karl Czajkowski]

Ali: I am partial to the opening idea, e.g. that the posix application
element get its own user and group IDs that _only_ mean the user/group
settings for the execution.  I wouldn't want to see them get mixed up
in more traditional notions of user, e.g. the user or "account" to
which the job charges are accounted.

Even though these will sometimes (often?) be the same string, that
doesn't mean they are the same concept.  I think it is better to
organize the support for concepts based on how they are related to one
another in use, e.g. the posix set of parameters are separated from
the resource selection criteria, rather than to how they might appear
similar through the haze of abstraction.

I guess I am realizing that the User section bothers me because it is
trying to be a "stovepipe" abstraction among a set of more horizontal
"layers" like resource selection and job configuration. I think better
layers to go with these would be "authentication and authorization
tokens, assertions, etc." and "accounting".  Each of these may have
some aspect of "userness" in them. :-/

karl


On Apr 12, Ali Anjomshoaa loaded a tape reading:
> 
> Many thanks for this Michel. There is a missing issue. Fairly high up on
> the list should be the issue about what to do with the User and Group ID
> info/elements? We've carried this issue over from the previous discussion
> and discussed it at length on the list. We just need to finalise our
> decision and move on.
> 
> Summary of my observation is that: 
> 
>   POSIX User and Group ID elements are required in the POSIX Application
>   section/element only for now. We can extend this for further application
>   types (e.g. Web Service invocation) by adding new, more specific, user
>   ID elements.
> 
> Other ideas are:
> 
> 1. Different user types in a User element, which can be added to later:
> 
> <User>
>   <POSIXUser/>
>   <POSIXGroup/>
>   <WebServiceUser/>
>   <OracleUser/>
>   <XindeceUser/>
> </User>
> 
...
> I'm in favour of 1. if we're to have a dedicated User element - i.e. not
> application specific like:
> 
> <Application type="POSIX">
>   <UID/>
>   <GID/>
> </Application>
> 
> as suggested in the opening paragraph.
> 
> Cheers and take care,
> 
> Ali
> 


-- 
Karl Czajkowski
karlcz at univa.com