[jsdl-wg] alternate view of Andreas's allocation model scenario

[Karl Czajkowski]

I thought a little bit more about this problem Andreas has and I think
I jumped to a solution too quickly.

Presumably, notions like whether you are getting "bare metal" or
"virtual machines" or "posix process startup" is indicated in the
application type.  So, the only remaining question is whether there is
some cross-cutting option that could change the behavior for a given
application model.

Let me give a sort of weak "proof by contradiction".  Assuming there
is some cross-cutting concept here, I think it would be called
something like "allocation model" and it has two enumerated values I
can think of right now:

  "total" allocations are what Andreas wants for his provisioning of
     node(s) for OS images.

  "partial" allocations are what Chris wants for placement of jobs
     onto shares resources.

The difference is that the partial allocation says "job is allocated
an abstract resource R1 which satisfies the resource selection
criteria and MAY be part of a larger resource R2".  The total
allocation says that "job is allocated a resource R and that's that".

Here's the contradiction: the difference between these is really
subtle and has to do with the "opacity" of the resource abstraction
(the so called "job container") within which the job is run. If the
job container is opaque enough, the job cannot tell whether it got a
total or partial allocation: a scheduler for POSIX jobs could use
system partitioning controls to create what looks like a smaller SMP
out of a larger SMP, for example!  However, a typical POSIX shared
resource has a transparent job container where jobs can detect the
larger, shared resource's characteristics. In addition, whether the
allocation is advisory or enforced is another related but separate
issue. I do not see how we can generically model either of these
aspects of allocation without citing behavioral aspects of a
particular application type's environment.

For me, one question remains: do we think it is in scope to define
different types of resource abstraction for the posix application
type?  In other words, does the JSDL posix application element need a
way to express whether the apparent machine (visible using posix
system interfaces) is allowed to be "larger" than the allocation given
to the job or not?  I am not sure there is a need.  The scientific
community has been using the transparent abstraction for years, where
the system MAY be larger and it is best for the application to "avert
its eyes". :-) Besides, we've already punted on how the application
learns what its allocation is and how the application processes get
started.  This allocation opacity issue seems quite metaphysical in
comparison...

I definitely think it is out of scope whether an "opaque" allocation
is using real "bare hardware" or some sort of virtualized machine, as
the distinction comes down to very different QoS concerns like
processor and memory performance.  This should be handled through
extensions and additional context like WS-Agreement, etc.


karl

-- 
Karl Czajkowski
karlcz at univa.com