[ogsa-bes-wg] RE: [jsdl-wg] Questions and potential changes to JSDL, as seen from HPC Profile point-of-view

[Marvin Theimer]

Hi;

Comments in-line.

Marvin.

-----Original Message-----
From: Donal K. Fellows [mailto:donal.k.fellows at manchester.ac.uk] 
Sent: Monday, June 12, 2006 2:45 AM
To: Marvin Theimer
Cc: JSDL Working Group; ogsa-bes-wg at ggf.org; Ed Lassettre; Ming Xu
(WINDOWS)
Subject: Re: [jsdl-wg] Questions and potential changes to JSDL, as seen
from HPC Profile point-of-view

Marvin Theimer wrote:
> If we narrow the definitions of mountpoint and mountsource enough and 
> precisely describe their semantics then we might arrive at something 
> that could be fairly widely used.  I'm thinking of things like saying 
> that you can't navigate "out" of a file system via "cd ..", etc.  This

> is definitely something to explore. 

Change "can't" to "shouldn't" and I'd agree. I don't regard the mount
stuff as being a way of describing security enforcement points. Systems
can do it that way, but at least some won't.

[MARVIN] The main thing I'm after is that the behavior of trying to step
"outside" the mountpoint by cd'ing out the top must be either (a)
prohibited or (b) explicitly marked as undefined in its behavior, with
an error fault potentially being generated.  This is because in the
Windows world I can imagine that a mountpoint definition might map to
setting up a drive letter and you can't cd up out of a drive letter.

In fact, I'd be happy enough with the profile stating that paths in JSDL
documents should not contain either the "." or the ".." elements at all.
That's a fairly strong requirement and guarantees that the job won't
fail on systems where your style of semantics are enforced.

> Since the HPC profile base case treats data staging as being 
> out-of-scope, the base interface profile will exclude these; but that 
> can be done independently of anything else.  (And, of course, the data

> staging extension to the HPC profile will need to deal with this
subject 
> in any case, even if it's ignored in the base case.)

Perhaps. Virtual FS references also sneak into arguments, stdio
redirection, working directory specs, and environment variables, all of
which may well need to be defined with respect to some VFS root. One way
of dealing with this is to define a minimal set of VFSes in the profile
(probably based on the JSDL set?) and state that profile-conforming job
submissions will only use those.

[MARVIN] Yes, but these references don't require the BES service to
parse the mountpoint and mountsource elements or do something like
execute a stat operation on the mountpoint to confirm that it properly
exists.  Excluding these elements from the HPC profile base case doesn't
mean that an implicitly required mountpoint doesn't exist, merely that
the compliant (BES) service is allowed to be oblivious to it.

> The HPC profile (and BES) /have/ to deal with the issue of describing 
> available resources.  So, one way or the other, the subject will get 
> addressed this summer.  As much as possible, I'd like to avoid 
> duplicating the work done in JSDL for that - if for no other reason
than 
> that users will likely be unhappy if they have to learn two different 
> ways of describing what they will perceive as being variations of the 
> core concept, namely resource description - both required and
available.

Sure, but you're using the elements to have subtly different meanings.
Not that I'm objecting; just pointing it out. :-) The best bet I'd guess
is to state that the published elements represent a description of the
maximal job (maximal capacity, most specific capability) supported by
the container.

You'll also need to manufacture a way of describing the set of apps (and
other related things, like libraries) supported. I don't think that the
way JSDL does this (even under the "maximal" interpretation outlined
above) is going to work in a sane-enough way.

[MARVIN] All very good points.  But I'll have to make progress on this
front one way or the other ...

> Any advice on this subject would be greatly appreciated.  As I said 
> above, I have to deal with this subject one way or the other and would

> prefer to do so with the minimum of feather-ruffling (while still
making 
> progress that results in a usable HPC profile by the end of the
summer).

You've got a mandate to ruffle feathers. You're writing a profile. JSDL
isn't a profile, and so we (with my JSDL hat on) need to be a little bit
more circumspect, if only to keep the noise down. :-)

> If you allow for the notion of file systems and mount points to be in 
> the core spec then I would argue that you are implicitly buying into 
> systems that also support the notion of current working directory
(some 
> jobs may of course not use it).

Good argument. :-)

> I would argue that one not specifying allowed/disallowed behaviors is
a 
> bad approach when interoperability is at issue.  (I'm talking about 
> disallowing "cd .." out the top, not disallowing change-directory
within 
> the subtree specified by a file system element.)

I'd certainly say that it is a feature nobody has to implement, and
which no interoperable job may make use of. (I don't see any way of
preventing the job itself from trying to do a 'cd ..' internally, nor
even any way to properly analyse whether the job will try to do it. Any
security checks required by a VFS interpretation must still be enforced
at runtime anyway.)

[MARVIN] Agreed.

[re root filesystems]
> Again, from an interop point-of-view, this seems dangerous.

This seems to me like an argument in favour of not including ROOT in the
HPC profile. That doesn't cause me problems, though I suspect that
everyone building a BES on top of unix will add it. (Who knows, perhaps
it would be in a POSIX-HPC sub-profile?)

[MARVIN] I think the HPC profile should say that specifying ROOT will
result in undefined behavior: the compliant service is free to accept
the specification, ignore it, or raise a fault.  Similarly, if an
activity is created then it must be prepared for undefined behavior if
it tries to use ROOT in a file name that it opens.

> Regarding your reactions to my straw man proposal, it seems like you 
> pretty much agree with everything except the following:
> 
> *        You're not convinced how universal the posix extension
elements 
> for things like command-line arguments and working directory are.  My 
> response is that I think they are at least as universal as the data 
> staging elements.

I'm likely agree with you there.

> *        You don't want to move the data staging section out of the
core 
> specification.  For the HPC profile base case, data staging elements 
> will be prohibited since they are out-of-scope for the base case.  The

> HPC profile extension for data staging will allow the JSDL data
staging 
> elements.  Whether or not these should be in a separate JSDL extension

> or whether they can be generalized to cover a wide(r) range of systems

> is a topic for future discussion.

Sounds fair enough. The inclusion of data staging was so that JSDL would
be relevant in cases that don't really match the HPC case, such as
clusters where everything has to be staged into the machines for
anything at all to work, and where no real workflow coordinator was
available. (Myself, I prefer the data staging to be in a separate
workflow step, but workflows are not really in scope of any GGF working
group at the moment.) IIRC, it was Darren Pulsipher who had this use
case.

> *        You're leery of tackling the resource description problem.  
> Understandable, although the HPC profile working group will have to
and 
> will be seeking guidance from the JSDL and other communities on how to

> do so.

I think it's hard and some people have very entrenched views on this.
But I also think that you can get something workable for the 90% case
together in short order here. I suggest that the "homogenous container" 
model under the maximal resource interpretation is good enough. :-)

[MARVIN] Definitely an approach that we should look at carefully. :-)

> Is that a fair characterization of your position?

Pretty fair. I can't speak for whether it is a characterisation of
anyone else's position. :-)

Donal.