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

[Peter Lane]

On Jun 8, 2006, at 6:34 PM, Marvin Theimer wrote:

> 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.
I still don't understand what you're getting at here. I don't see  
this as the two interfaces are mutually exclusive. I just don't see  
any point of having identical operations for both the BES/activity  
factory service and the activity service. If the factory and activity  
service were the same, then fine. If they are two distinct services  
then tailor the interfaces. You mentioned "keeping them in sync". I  
still don't understand your concern here. What is it that frightens  
you about the BES group being able to keep the two (which are  
intimately related) in sync?
> ·        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 J).
>
>
>
> 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
I would rather see a generic property getter method instead that  
takes an array of EPRs. This would model better w.r.t. WSRF's  
getResourceProperty, etc... methods and avoid the precedent of  
providing individual operations for each property.
> ·        CancelActivity(EPR)
>
> ·        For non-WSRF versions: QueryResources() à  
> schedulerResourcesInfoset
It worries me that this is a non-WSRF-only operation. We should try  
very hard to avoid branching the spec for two different resource  
models. If we can't avoid it then there needs to be two separate  
specs IMHO. What do the WSRF services do with this?
> ·        ‘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.
I don't really understand what you're trying to accomplish here. You  
say it's a non-WSRF operation and yet this description says it's an  
aggregation of the WSRF RPs. Then you add that it might return other  
stuff as well. This seems like a "give me the serialized resource  
object" operation. My feeling is that if the necessary information  
were exposed correctly you wouldn't need this operation.
> ·        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/20060610/db6608f1/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2782 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060610/db6608f1/attachment.bin