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

[Marvin Theimer]

Hi;

 

Outlook seems unable to do a proper job of incorporating a copy of your
email into my reply, so I will reply to your points separately from the
in-lined original email:

*	I would agree with you that security around messaging itself is
out-of-scope.  I do believe we need to think about how to deal with the
credentials used for running activities.  Without that, it will be
impossible to define an HPC profile that actually enables a working,
interoperable system.
*	I'm confused about your statement that extension profiles are
out-of-scope.  Assuming that BES will become an extensible specification
- which is implied by its acceptance of an extensible state diagram
model - then we have to define how extensions can get written and allow
for the BES WG to define a few for some of things that were in the
original BES spec, such as data staging and suspension.  
*	From an HPC profile point-of-view, we have to be able to
describe BES containers that represent compute clusters.  Otherwise, the
HPC profile will not be able to achieve its goals using primarily BES
and JSDL.  That is, it would need to define another interface for
describing a cluster's resources.  That, in turn, would make the
equivalent aspects in the current BES spec redundant.
*	If we want interoperability then we have to define normative
values for things like LocalResourceManagerType.  That doesn't preclude
the notion of allowing non-normative ones to be employed by clients and
services that have an implicit understanding amongst themselves.
*	The problem with simple statements about security is that they
don't enable interoperability.   So by defining an EPR for something
like a job credential service, you're implicitly introducing an interop
requirement that all parties must figure out how to adhere to.

 

Marvin.

 

 

________________________________

From: Peter Lane [mailto:lane at mcs.anl.gov] 
Sent: Monday, June 05, 2006 5:02 PM
To: Marvin Theimer
Cc: ogsa-bes-wg at ggf.org; Ed Lassettre
Subject: Re: [ogsa-bes-wg] Questions and potential changes to BES, as
seen from HPC Profile point-of-view

 

 

On Jun 5, 2006, at 5:19 PM, Marvin Theimer wrote:





	*        Interface for directly controlling/manipulating an
activity once it has been created.

Yes, I was concerned about this as well but never said anything. Generic
operations for manipulating or introspecting activities (i.e. factory
operation that takes an activity ID) can be useful, but I definitely
agree that there should be an activity service interface with operations
that imply the activity via the EPR.



	*        Given that BES has bought into the notion of an
extensible activity state diagram, it needs to also normatively define
how clients can learn of the extensions that a given BES service
supports.  Is that something that will be added to the BES
specification?  Or will the specification point to some other place
where notions of extensibility are defined more generically?
(Personally, I'd vote for the former approach.)

Good point. I'd also prefer adding something explicitly to the spec.



*        Previously included states, such as Execution-Pending, will
presumably be defined in suitable extension profiles?

My understanding is that this kind of thing is out of scope of the spec.
I would assume that if there were any defacto standards being used in
the community that this would at most be a separate OGSA-BES WG spec.



*        RequestActivityStateChange: I believe this operation will pose
challenges in an extensible design.  The current design is imperative by
nature: it specifies an explicit state to move an activity to.  However,
a client who does not know of all the extensions that a BES service
implements may not know how to pick the appropriate state to transition
to.  It seems better to introduce a more declarative approach in which
clients specify "actions" they wish to occur, such as 'CancelActivity'.
This approach would allow the BES service to make the appropriate state
transition in response to a desired action requested by a client.

Yes, this is what I argued as well albeit from a slightly different
angle.



*        JSDL seems to inherently be focused on describing a single job
or a single computational resource.  For example, it has no notion of
describing all the differing compute nodes of a (heterogeneous) compute
cluster.  By incorporating JSDL elements into the BES information model
it seems that BES is foreclosing the ability to describe things like
compute clusters.  This issue also effects what can get returned from
GetActivityJSDLDocuments.  If I'm wrong about this, then it seems like
it would be worth having an explicit explanation about how to achieve
this functionality somewhere in the specification.

I think I complained about this here as well. Certainly I've complained
to the JSDL people and the ESI people about this. The JDSL people
answered something about keeping it simple for now. My guess is that
people see it for the daunting task it is an prefer not to address it.
I'm not criticizing anyone for this. It's just my take on the problem.



*        These operations seem to require a different set of
authorization credentials than the other interface operations since they
should be invoked by system administrators rather than random users.
How will that work, given that these operations are in the same WSDL as
the other operations?  Wouldn't this argue for moving these operations
to a separate system management interface?

This is why I suggested that security was out of scope. The Globus
Toolkit, for example, has no problems specifying different security
parameters for different operations. It's all proprietary configuration,
though, and probably should be. That said, I believe I said something
similar to this in my original comments on the spec. This sort of thing
feels to me as well like it shouldn't be in a basic execution service
and should be an implementation detail as to whether the management
interface is exposed as well as the BES interface.



*        Since JSDL documents are self-describing, a BES service can
figure out by inspection whether the job description infoset parameter
to CreateActivityFromJSDL is JSDL or something else.  This would seem to
imply that naming the operation CreateActivity would lose no information
and would allow for transparent extension to other job description
infoset simply by using them (assuming they are self-describing).

Yes! I argued to chop the suffix as well, but this makes the point
better.



*        LocalResourceManagerType: where do these get defined
normatively?

I would argue against explicitly defining values for this. It eliminates
much of the flexibility the implementation has in terms of what local
resource managers it can support.



*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060607/3725555d/attachment.html