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

[Ian Stokes-Rees]

Hi,

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.

A few comments on the 0.9.5-01 specification from someone who has never 
looked at it before:

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.

Namespaces: You have probably already had lots of discussion on 
namespaces.  There can be problems with forwards and backwards 
compatibility of schemas if you make the namespace the same as a 
resolvable URL.  Things like "bug compatibility, processing 
repeatability, existing JSDL documents, existing JSDL-aware services all 
come into play.  My 2 cents would be that date-based versioning is a 
good idea, and that you should not get some kind of philosophical 
hang-up about versioning and namespaces (e.g. "But the *plan* says that 
version 2.0 will come out in 6 months time!").  Transparent schema 
changes which keep the same namespace are typically OK so long as:

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

This amounts to "Minor changes result from a relaxing of schema 
constraints" (e.g. a mandatory element or attribute is now optional)

Any schema changes which would invalidate existing valid instance 
documents really mean you need to change the namespace (major version 
change).

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.

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

"Numerical operators can be used through the general XML extensibility 
mechanism. For example:"

Is that to say JSDL asserts "There shall be no numerical operators", or 
that JSDL simply doesn't have anything to say about numerical operators? 
  What is the point of listing 5 operators but then having a 6th in the 
example XML (greater than >)?  I also don't see what "general XML 
extensibility mechanism" has to do with anything.

Comment: Your pseudo-schemas are very nice.  Glad you opted *not* to 
include the raw XSDL, which generally obscures the structure it 
represents very effectively.

Normative XML Schema Types: It is not clear to me what you mean by this 
section.  For example, what is xsd:any##other?  or "Complex"?  Is that 
to say those are the only types you allow?  Surely not, but then what 
does 4.2.1 mean?  I don't think 4.2.1 adds anything to the 
specification.  I'm guessing you just mean "The following built-in XSDL 
types are used in JSDL ...", but so what?  And "any##other" is not a 
type, nor is "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").

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?

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.

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

cardinality (*,+,?, etc.)
description
parent element
data type (string, numeric, enumeration, etc.)

Maybe alternately organizing this list alphabetically, but grouped by 
element "category" would be useful.  THe current "sections" format is 
very difficult to scan to pick out useful information.

Regards,

Ian.

Ali Anjomshoaa wrote:
> There is currently no definition for the UserCredential element in the
> Spec, but, there is one for UserGroup - anyone able to explain this? The
> UserGroup element's definition says that it contains the credentials
> necessary to run the job in a Grid!
> 
>>The management and establishment of credentials, on the other hand, is
>>generally very dependent on the protocol being used and the specific context
>>of the job submission itself, that it doesn't make sense to put this in a
>>job description. Having just finished a project Kerberizing one of our
> 
> I agree with Chris here. It doesn't make sense to have credentials in the
> JSDL. We decided in Berlin that security and credentials were out of
> JSDL's scope. We shouldn't let them creep back in!
-- 
Ian Stokes-Rees                 i.stokes-rees at physics.ox.ac.uk
Particle Physics, Oxford        http://www-pnp.physics.ox.ac.uk/~stokes