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

[Marvin Theimer]

Hi;

 

My initial email had the intended effect of generating some good
discussion.  This email is an attempt on my part to try to distill what
I took out of those discussions.  Feedback, corrections, and extensions
are welcomed.

 

The main topics that seemed to generate significant controversy were the
following:

*        The relationship of the BES "array" operations for interacting
with multiple activities in a batch manner versus the (system
management) interface that should be offered via the EPRs corresponding
to individual activities.  

*        How BES should describe the available resources its associated
execution container has - especially when that container might be a
compute cluster or the BES service might be a meta-scheduler fronting
multiple backend BES services.  Most of this controversy was really
around the details of the JSDL specification and how to use it rather
than around BES proper.

 

The rest of my suggestions did not seem to draw much fire (or maybe I'm
just blanking it from my mind :-)).  

 

Given that, I would like to propose the following second draft of my
proposal for how to change BES in order to support the HPC profile work:

*        Operations:

*        CreateActivity(jsdlDoc) --> EPR

*        GetActivity(EPR) --> activityState

*        GetActivityDescription(EPR) --> JSDL doc

*        CancelActivity(EPR)

*        For non-WSRF versions: QueryResources() -->
schedulerResourcesInfoset

*        'schedulerResourcesInfoset' is essentially the union of the RPs
that would be exported in a WSRF-based version for describing the
resources that are available for use at this BES service.  Note that a
BES service might also want to expose other kinds of information that
would not be returned from this operation - this operation is there so
that clients can determine whether or not a BES service could
potentially meet their needs and is necessary for meta-scheduling
scenarios.

*        One might argue that one could use WS-Transfer for this
operation.  However, since a BES service might want to export other
kinds of information, this would require an extra level of indirection
so that the BES service could expose which EPRs to use for retrieving
which kinds of information.

*        Information model for describing available resources:

*        Define an infoset that can describe such resources.  The
top-level element indicates which description standard is being employed
by the infoset.  

*        Define one such description standard to be an array of JSDL
descriptions for things like compute clusters.  Other, richer,
description standards can be defined later.

*        Additional topics/summary:

*        Simple state diagram and no notion of array operations, data
staging, suspension, or notifications in base BES case.

*        Extensions defined as separate profiles for array operations,
data staging, suspension, and notifications.

*        Defer the topic of how the interface for (extension) array
operations should relate to the interface supplied for
querying/canceling individual activities.

*        RequestActivityStateChange replaced by operations specifying
desired actions rather than states.  Base case supports activity
cancellation; extensions can define additional operations (e.g.
SuspendActivity).

*        Information model: small base set plus extensions model (which
ones to include in the base set TBD)

*        All system management functions moved out to a separate
interface.

*        Provenance log: (eventually) define an extension for a
GetActivityProvenance operation.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060608/611083fe/attachment.html