Minutes for BES -- 9 June 2005

Attendees
---------------
	Mark Morgan (Minutes)
	Andrew Grimshaw
	Darren Pulsipher
	Fred Maciel
	Chris Smith
	Hrabri (Intel) (Last Name?)
	Karl Czajkowski
	Steve McGough
	Tom Maguire

* Agenda Bashing
* Discuss Draft Specification
* Batch/Posix Port Type
* Meta-model discussion - JSDL, CIM, other.

* Draft Specification
	- Andrew started taking the draft that was started in Seoul and started putting it into GGF Normal Form
	- Went over changes and additions
	- JSDL assumes that there is some kind of local storage that you can stage something into or out of.
	- If a BES container can model a cluster (like an LSF queue) then when we say copy-in or copy-out, the implication is that that storage is visible
	  anywhere that the activity can execute in that container.  This is the locus of exectuion -- where it executes has to be able to access the data given.
		-- That makes since.  JSDL describes that, but probably not as well.
		-- Will start using this phrase, "Locus of execution".
	- There used to be an AbstractName parameter to createActivity that we are taking away.  Now that we have JSDL, we don't need this.
	- When it comes time to generate WSDL, we will have to pick a rendering.
		-- You have a spec, and you have a profile of that spec in a particular rendering.
		-- In the case with OGSA-WSRF-Base Profile you would have a rendering in that language.
		-- In 3.1, we can fill out a little more about createActivity, we fill in a few more details, but basically we have to get abstract details, and then
		   we will have additional.
			-- Let's give InfoSet
	- For the AbstractNames that comes back we will have to give a rendering.
	- This document already talks about things that are rendering specific.
	- Without the rendering, it's unclear that there is much use to the document.
	- Given the abstract spec, can you not come up with a profile that is renderable in WSRF
	- Feel like, at most the abstract spec is only an information document.  It's our notes on how to do the rendering.
	- That's why Andrew liked having the abstract document as well as a rendering piece in WSRF-Base-Profile.
		-- Does this bias us too much towards a given profile
	- InitiateActivityFromName -- deprecated
	- GetActivityStatus
		-- Darren was to take the lead on specifying the format for the result document from this call
	- TerminateActivity
	- There are a whole bunch of activities that are management activities on the container.  How much do we put in on the container, and how much do
	  we wait for others to put them in.
		-- A few of them seem really fundamental.
			--- StopAcceptingNewJobs
			--- StartAcceptingNewActivities
		-- But it seems so clearly out of scope for this group.
		-- This is where CIM comes in doesn't it?
		-- Yeah, it could be.
		-- The service is going to need to have multiple interfaces.  Some will be the functional ones, but there will have to be a management
		   interface.  Question is, is the management of this container in or out of scope.  If it's in scope, then we should be dealing with CIM and
		   the other standards.
		-- Problem with CIM is that it's not clear that it covers some of the use cases that we can imagine.
		-- Maybe we should just keep it out of scope
	- In terms of security, a lot of administrators would prefer that you have a completely different interface where management is done through rather
	  than a single interface.
		-- That's going to be access controlled though.
		-- A lot of people separate the functional interfaces from the monitoring, from the management interfaces.  It's always a tricky thing though.
			-- What is functional, what is management.
		-- We are only defining interfaces.  How people mix those interfaces is up to them.
		-- We have gone to an extreme where we have one operation per interface
		-- Maybe we should take out stop and start accepting but instead at the beginning of the document just say that "management is important
		   for example stopping and starting accepting", but that it's not in scope for this document.  Would people be comfortable with that?  Yes!
	- ActivityStates
	- Meta Model
	- Security Considerations
		-- Significant
		-- Would identity mapping be in scope or out of scope?
		-- Does specifying a unix user actually mean a bad thing?  It's still subject to other things like access control and security.
		-- Andrew to re-write security section to point this out
	- Andrew to send out another version soon
* Posix/Batch Port Type
	- What about Windows.  Most of these make sense for Windows, but not all
	- From a job management perspective, some times you don't care whether it's running on Windows or Unix
	- Have found it useful to interact with the file system where that job was running.  Copying files, etc.
		-- In SAGA interface, we do talk more about interactive jobs, etc.
		-- This seems kind of orthoganal and out of scope
	- It's pretty easy to do an activity port type.  Hope that we can make this inscope for BES
	- Would like to see this go into the overall document
		-- Chris Smith to do this
	- Chris and Darren to work together on doing the states.
* Agenda next week will be state, and meta-model
* Week immediately before GGF, No telecon
* Chris to write section in word for port type, and Andrew to drop it in.