[jsdl-wg] my view on execution user and group

[Donal K. Fellows]

Ian Stokes-Rees wrote:
> First off, a brief introduction.  I've been lurking on this mailing list 
> for a couple of months but not reading too many of the posts.  I'm doing 
> a PhD on task scheduling for computational grids and now realize I 
> should have been following JSDL discussions a little more closely.

Hi! I'd like to start by telling you that standardization is very much
about the art of the possible. Keep this in mind as you read my replies;
it tells you much about why things are the way they are...

> Figure 1: Job Manager/Scheduler has two directed arrows and JSDL bubbles 
> for both.  None of the other "links" do.  I sort of understand why this 
> might be, but really it just looks confusing.

Both figures need more work. (In this case, the two arrows are to
indicate that the vision of the JM/S connection is in terms of JSDL
rewriting.)

> Namespaces:
[...]
> 1. All systems using the schema can be updated "instantly"; and,
> 2. Any formerly-valid instance document is still valid.

I don't disagree. These things are not an issue *yet* as anyone using
JSDL now really ought to be aware that they're using something that is
pre-release and should be prepared to adapt what they're doing, but the
issues clearly will matter going forward.

> Plethora of "Job Languages" in order for job submission to work: My gut 
> feeling is that you are dreaming if you think all these "envisioned" 
> languages will independently materialize and precisely manage to 
> interface -- that is, have consistent semantics, not overlap, and not 
> leave any gaps.  Isn't it necessary for one group to try to grapple with 
> all these issues together in one place?  Just labling the issues as "out 
> of scope" may result in a situation where JSDL is sufficiently 
> incomplete as to be unuseable in practice, which would be ashame.  It 
> is, of course, extremely valuable to have identified and decomposed the 
> "big picture" into these sub-requirements.

Here's where what I said above about the "art of the possible" comes
into play. The full picture of what you're talking about is both
immensely contentious (perhaps more than it ought to be) and complex. We
have tackled this by scoping right down what we are seeking to do so
that we can get more people to buy into it (i.e. so that it is a
standard; without buy-in, it's just a document gathering dust) and so
that we can get relatively rapid agreement. The issues relating to the
other areas of the job description and management picture are both more
complex, and more heavily occupied by "armed camps".

By scoping down as we have done, we have nearly finished a useful subset
of the overall functionality (the previous situation at the ground level
was dire, or perhaps even something of a joke) and a foundation from
which to build the higher-level specs. Note that now that JSDL is just
about there, there are moves afoot to get other groups going to fill in
the other parts of the picture.

> Numerical Operators:  It is not at all clear to me what the following 
> sentence or the example XML are supposed to indicate:

I think we could probably just drop that subsection entirely. The range
scheme covers just about everything useful that isn't obscenely complex.

> OSType: That is an odd list.  For example, you mix software versions 
> with base operating system for Windows, but not for Linux.  You even 
> provide Windows 64-bit specialisation as a specific "OSType", but don't 
> do the same for anything else.  Surely elsewhere 64-bitedness or OS 
> version will have to be "labelled" for other OSs' (e.g. "RedHat 7.3" or 
> "RedHat Enterprise Linux", or "REL, 64-bit").

That list of types is defined by the DMTF in CIM, and it is good
politics to use external standards where appropriate.
     http://www.dmtf.org/standards/cim/cim_schema_v29
(I think it is over-specific, but there you go.)

> ExecutionGroupID, Hostname (and others bits): These seem to go against 
> the idea that you are not going to support security aspects in JSDL, but 
> then the user can assert groups or hostnames which may require a 
> particular authorization token in order to access or complete the 
> request.  Something will need to provide a mapping which says "Use this 
> token to be able to exec in group X or on host Y", don't you think?

We used to have this mechanism (called Profiles) but we removed it. It 
belongs in the scope of other specs (e.g. WS-Agreement).

> jsdl: namespace prefix: In the examples, sometimes it is used and 
> sometimes it isn't.  If there is a reason for that, it isn't clear to me.

That's a clean-up task to be done. ;-) Have you raised it as a tracker
item on GridForge?

> Final comment: it would be nice to have a single tabular summary of all 
> the "elements" in JSDL along with:

That'd be nice, but it is something for a non-normative appendix and
should only be done with a tool starting from our final-candidate
schema. Or it could go in a Primer doc, of course.

Donal.