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@univa.com