[jsdl-wg] Issues for todays phone conference

Donal K. Fellows donal.k.fellows at manchester.ac.uk
Tue Apr 12 08:39:34 CDT 2005


Karl Czajkowski wrote:
> 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.

I also feel that the notion of "who pays for the job" is unrelated (or
at least sufficiently so to be outside our scope). At the very least, we
can ignore such stuff for 1.0 :-) (Our main use-cases link that notion
of accounting more with the notions of VOs, but we know we need more
work in this area.)

> 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 feel that user/group is for specifying the ids in the *rare* cases
when a job absolutely must run as a particular target system identity.
The rest of the time, it's either stated through some other elements
that we're saying nothing about, or implicit in the job submission
context in some way and that'll be the right thing (and out of our
scope, hooray!)

> 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. :-/

The only concern about having the values inside the PosixApplication
element type (or whatever the current name is) is how to ensure that the
inward data-transfers ensure that they pick up the correct ownership
information. I don't think we express the notion of whether a job wants
to write to a staged-in file or not, which means we have to assume that
it might... :-/

Donal.





More information about the jsdl-wg mailing list