[jsdl-wg] my view on execution user and group
Ian Stokes-Rees
i.stokes-rees1 at physics.ox.ac.uk
Fri Apr 1 10:26:06 CST 2005
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
More information about the jsdl-wg
mailing list