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

[Karl Czajkowski]

On Jun 09, Marvin Theimer modulated:
...
> Agreed.  Also, one possibility is to explicitly specify some of the
> commonly occurring “semi-bound” scenarios, such as “any x86”
> architecture.  I’m not familiar enough with the CIM world to know if
> they can provide us with guidance on how to solve the problem in
> general.
> 

It is a flat enumeration set, I believe, so some logical composition
model would be required, e.g. "give me cpu type i386 OR i486 OR
pentium OR pentium-m OR opteron ..."

BTW, I sometimes wonder if CIM is the right model here.  The above
values are a subset of those available to GCC to control ABI and
processor-specific optimizations.  They seem pretty aggressive about
introducing new processor support in a backwards-compatible
manner. Perhaps a slightly "weaker-typed" constraint ought to be
defined to accept strings which are interpreted as a
compilers-specific concept?

I haven't thought about this too much, so maybe I am off base. But in
some sense, compiler settings are closest to what the user/app really
cares about for predictability.  On the negative side, it means having
to support multiple compiler-specific namespaces for these
constraints, and having reasonable best practices for translating
between them in service implementations.


> 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. 
> 
> 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.)
> 

I'm not sure if scoping away staging means we can ignore storage
system structure. How will one compose a staging service activity with
a compute activity if there is no underlying model for how the storage
is manipulated and named?


> 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).
> 

Personally, I think it is silly to say that a "space" can be claimed
by others!  Anyone with good ideas and willingness to contribute
should feel free to develop ideas.  If they are great, maybe the
others will realized they would benefit by working together. If the
others are unsure, maybe there will have to be competing proposals and
a decision made in the marketplace... top-down architecture really
doesn't work very well with voluntary, collaborative projects.


karl

-- 
Karl Czajkowski
karlcz at univa.com