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

[Peter Lane]

On Jun 7, 2006, at 4:29 PM, Marvin Theimer wrote:

> 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 guess I'm still confused about what you are asking to be addressed.  
How actual credentials are used seems like an implementation decision  
and thus out of scope of an interface spec.

> 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.
Sorry, I didn't mean that defining *how* extensions are added was out  
of scope. I just meant that the actual implementation of those  
extensions is out of scope. I think any extensions should be defined  
in a separate spec. If not, then I don't see why it's an extension to  
the spec. ;-)

> 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.
I'd agree with this. Have a normative set but also don't restrict to  
just that set.

> 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.
True, and yet that's what the BES spec is basically doing with  
activities as well. It gives you an EPR to *something*. So if we are  
consistent about this interop philosophy then we really ought to  
define the activity interface within the same spec.

>
>
> 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/20060610/98e7c8f9/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/98e7c8f9/attachment.bin