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

[Peter Lane]

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

> ·        Security design.
I would argue that this is a WS binding issue and is out of scope of  
the spec. I think the best that could be said would be that some sort  
of security is implied since the implementation has to be able to  
differentiate between users.
> ·        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.
> ·        Extensibility:
>
> ·        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.
> ·        Is the “base case” for BES now fig.2, which shows states  
> of {new, pending, running, canceled, failed, finished}?
>
> ·        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.
> ·        Given that suspension is no longer in the base design,  
> presumably the createInSuspendedState parameter to  
> CreateActivityFromJSDL should disappear?
Yes, this is something I picked on as well. It should be a JSDL  
extension anyway, but certainly this becomes mandatory if suspension  
is an interface extension.
> ·        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.
> ·        Information model:
>
> ·        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.
> ·        Is there any notion of specifying that all compute nodes  
> should have the same value for some attribute (e.g. CPU  
> architecture, CPU speed, NIC card)?  This seems to be missing from  
> the JSDL specification, but seems very important for BES if it is  
> to support things like compute clusters.
This relates to my last comment. All these related specs have assumed  
that the node composition is homogenous.
> All this leads to the question of whether BES will have a notion of  
> extending the information model that is supplied. If so, then that  
> leads to the question of what the base case should be and whether  
> it should include a smaller set of things than is currently listed  
> in the spec.
Good point.
> ·        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.
> ·        Given that BES seems to have bought into the notion of  
> extensibility, should the base case be a “non-array” one?  For  
> example, currently if you want to handle a fault for a  
> RequestActivityStateChange operation on a single activity you need  
> to look inside the returned array of results to see if a fault  
> infoset was returned.  All the exception handling machinery that  
> modern tooling provides can’t get used because  
> RequestActivityStateChange never returns an actual fault message  
> (as compared to a fault infoset for the appropriate array elements  
> that are returned.
Good point, and more reason to have a separate activity 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.
> ·        Container attributes that I have questions about:
>
> ·        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.
> ·        Job Credential Service and File Credential Service:  these  
> imply a specific security model.  Given that security is undefined  
> in the BES spec, is this appropriate – especially given the rather  
> vague definition of both?
I think the simple statement that some sort of security is required  
should be sufficient to justify generic EPR properties.

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060605/7bd899ed/attachment.htm 
-------------- 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/20060605/7bd899ed/attachment.bin