The session quickly covered the Spec with very few minor changes and/or comments.

Then we discussed the future of BES. The following are the notes that were taken about the discussion.

Future BES additions, extensions,etc…

What information model should be used to represent the container

Consistent way of exposing types of JSDL Application can support.

How do we expose the information so a scheduler can chose the container?

Query for Activities based on attributes both static and dynamic

When JSDL adds different Application types BES needs to handle this. For example an mpi jobs may change the state model or how many activities are returned from a createActivityFromJSDL.

Can we make a generic state model that can handle all new application types that JSDL could have.

Does the state model need to change for reservation? How is the activity bound to the reservation?

Advanced Execution Service

Reservation System (WS-Agreement) maybe add makeReservationFromJSDL

Scheduling constraint policies on BES container

Example is stop accepting activities for a period of time or when the load is at something etc…

Outside groups need to do

Activity Management Interface should be defined

Management interface for OGSA services should be defined.

WSDM ?

Workflow Execution Service?

Resource Utilization of the execution element that the container represents.

QOS and capacity

* Andrew Grimshaw raised the need of an interop fest. GridSAM (William Lee) and Mark Morgan (UoV) agreed to provide public endpoints. Mark Morgan has 'ogsa_run' .NET client for testing. GridSAM will provide an all java client.

* Steven N. mentioned Chris Smith will bring up a query on the need of a 'Holding' state in the overall status. This will be raised in the public comments.

* Steven N.: The states in BES are aligned with those in CIM. SAGA is looking at the BES state diagram.

* William L. & Andreas S.: Can the client request any state changes? Yes. If the state change cannot be satisfied or illegal, the appropriate negative response would be returned.

* Activity interface is out of scope. A BES profile document will mandate the JSDL application type to be allowed and the activity interface to be made available. 

* Steve L. commented that WS-I rendering can use WSRF BaseFault. Darren P. replied that for political reason the WSI rendering should be free from any WSRF artifacts.

* Mark M. suggested we should have the ability to express advance reservation, scheduling constraints, utilization.

* William L. suggested we should have the ability to express the JSDL optionalities a BES service supports. For example, POSIXApplication, file staging bindings.

* NAREGI is using BES with extension in JSDL to handle advance reservation.

* Stephen P. raised the question of whether it makes sense to expose resource utilization in the information model. Donal expresses concern in whether this is in scope for a 'BASIC' execution service. Stephen P. thinks this might raise false expectation.

* Steve McGough suggested there's a need for querying job based on attributes.

* Ali A. commented whether the generic state model can support other JSDL application types (e.g. Web Services). Can we abstract it further?

Darren Pulsipher

Darren Pulsipher
Owner

Email: darren@pulsipher.org IM: darren_pulsipher (Yahoo) Professional Profile Pulsipher Site

Ovoca

See who we know in common

Want a signature like this?