[ogsa-wg] Telecon Minutes for OGSA BES (21 April 2005 and 28 April 2005)
Hiro Kishimoto
hiro.kishimoto at jp.fujitsu.com
Thu Apr 28 20:00:36 CDT 2005
Mark's email bounced.
----
Hiro Kishimoto
Subject: Telecon Minutes for OGSA BES (21 April 2005 and 28 April 2005)
Date: Thu, 28 Apr 2005 13:10:08 -0400
Here are the two telecon minutes documents from the first to OGSA BES
teleconferences. Andreas, can you point Me at the correct place on gridforge to
be putting these?
-Mark
--
Mark Morgan
Research Scientist
Department of Computer Science
University of Virginia
http://www.mark-morgan.net
mark at mark-morgan.net
------=_NextPart_000_0012_01C54BF3.9A259EA0
Content-Type: text/plain;
name="Minutes - 28 April 05 BES.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Minutes - 28 April 05 BES.txt"
Minutes for BES Telecon -- 28 April 2005
Attendees
---------
Andrew Grimshaw
Mark Morgan (Minutes)
Steven Newhouse
Darren Pulsipher
Fred Maciel
Tom McGuire
Andreas Savvas
Karl Czajkowski
* Many presentations at GGF had something at the bottom end that started = up
services
- create
- instantiate
- submit
- etc.
- Took some kind of JSDL or something and returned some kind of handle
-- EPR
-- etc.
- Since that seemed like fairly consistent pattern, can we agree that =
that
is the pattern that we are looking for for factory like operations?
-- Yes
* Last call we agreed that we were going to work with both legacy jobs = and
service instantiation. Is there a consensus that this is the basic = approach
that we want to be taking here?
- No dissagreement.
* Karl brings up WS-Agreement.
- Concern about WS-Agreement is that going with it could stall the =
pipe.
- We are under pressure to have something tangiable come out of this
process in a fairly short period of time.
-- Waiting on WS-Agreement could hurt that.
- On the other hand, it seems like if we could come up with a basic =
thing
here, we could sometime in the future refactor in terms of =
WS-Agreement.
- Is there agreement that we should wait on WS-Agreement?
-- Would like to know more about the timing for WS-Agreement?
-- Current plan in the group is to try and have the next rev for
GGF = in
Chicago for another comment period. Hoping that this will be
a
"pat on the back" comment period so the hope is that it
might be
ready in a soon time frame (a few months).
- Is the draft in gridforge close to what is expected to be presented =
in
Chicago? How closely does this match what we are talking about here.
-- WS-Agreement is a WSRF based approach. Current issues
include
technical issues so the technology isn't frozen...there will
be
changes, but the basic idea is pretty close.
-- The factory pattern is to create an agreement. The operatoin
is
called createAgreement and it returns an EPR which is the
agreement
(in the synchronous case) or an EPR which you have to talk to
to = see
if the agreement was accepted (in the asynch. case).
-- That pattern isn't too far from what we have here.
-- The big difference is that what we are talking about here in
BES is
that there are other things that we have put into the
container = that
are more specific to container like things then to a general
agreement.
- Propose to the group, put on the agenda for next week, a discussoin =
of
how we want to deal with agreement.
-- Karl to send out mail with links to which documents we should
be
looking at.
-- Karl to confirm the projected schedule for agreement.
* Current Prototype
- What is the purpose of submissionIdentifier?
-- This is a message identifier, like UUID.
-- Question whether or not we really need this because JSDL
already = has
it.
-- If it's already in JSDL, then we don't need this parameter.
-- The objective is to eliminate duplicate requests.
-- We'll take the parameter out as an input, but replace it with
a
comment to indicate that we need this duplication detection
somewhere -- either at message/SOAP layer, or perhaps in
JSDL.
- Do we want to presume that something like WS-Names will be finished =
in
time?
- Leave it for now that it will be defined elsewhere. If we get down =
the
pipe and WS-Names aren't there, we will have to get more concrete and
= get
back to it.
- Punt for now on faults
-- one of the things we will have to figure out later is the
fault
model.
-- Mentioning the faults is good, but it's not time to talk
about the
mechanism.
--- We'll have a call later with "bring your own
favorite faults".
* getActivityStatus:
- We have a container for services that can be a hosting environment of
some kind, or something else.
- Will model some physical resource out there.
- What other kinds of things do we want to be able to do to containers.
- One is, give me the activity or status of one or more named things =
that
have been instantiated on this thing.
-- One of the arguments we've had on this is that, on the one
hand, if
everything is WSRF, then I should directly talk to the named
input.
-- This goes for a few of the operations.
-- The argument is to say that having two different functions is
to
have two different ways to do things.
-- But, sometimes you want to talk to the container to
do something
to a down or unresponsive object, or you want to do
bulk
operations.
-- If we have these get status things and the terminate
one in
particular -- sometimes you have to kill something
that isn't
responsive.
- Talking about the model, or the rendering, or both? One of the =
problems
the OGSA WG has to address very soon is the resource model for OGSA =
in
general (and mangement model) vs. the individual thing for individual
services and containers. A lot of the things that we are going to be
doing on containers are going to look like management things. You =
can't
just pull it away from the service -- they are inter-twined.
-- We are to have a discussion of this in London.
- You also have things that even a scheduler wouldn't care about that a
manager may care about like changing the policy on how to throw out
jobs on an overloaded (or overcommitted) resource.
-- Andrew told Hiro that he would prepare an example of the
kinds of
places this would show up.
- Karl votes in favor of this. Some discussion to separate notion of
job management from aggregate job management (kill this job, kill
all jobs).
-- Managers didn't like the ability to get the status of all
jobs.
-- In reality, you end up crippling systems to satisfy
requirements.
-- Security strickly speaking is out of scope, but in practice
you
have to think about it.
-- Let's make the assumption that someone above us is going to
handle
security, maybe with a document where they pass in there user
identification or credentials. The underlying system will
handle
that. You have to make assumptions that the implementation
will
handle this stuff as long as you believe that the user's =
credentials
will be passed. Leave it up to the implementers to implement
or
some security/policy working group.
- There has to be some linkage back to the original JSDL document. The
schema (format) of this document TBD.
-- It needs to have the activity identifier and the activity
state.
-- You return multiple activity states -- you may have multiple
data
staging -- how do I match them up.
--- You need to be able to name the states and match
them up with
things in the JSDL document.
-- Should the BES include data staging in it?
--- If you are thinking about the workflow to run a job
is
something that could take place outside of the
BES interface.
--- If there is an overall job manager, it could start a
small job
or service that does the staging for you.
That's a separate
job.
--- Depending on how we decide to do BES, you could make
all data
staging irrelevant.
---- We need to dive into this more
deeply.
---- How simple can we make BES by
pulling out things like
staging?
---- How simple "SHOULD" we make it?
* No desire to make the calls long then 1 hour.
* Final discussoin briefly is about the terminate with prejudice = function.
- Is returning the right thing to do?
-- We shouldn't return anything.
-- Boolean isn't rich enough.
-- You could get something back saying it's dead, there's
nothing
there, it's going down, etc.....from a practical sense,
there's a
bunch of terminate status as well....
-- It should either be an empty output, or some kind of fault
model or
something.
-- We should think about whether or not this is synchronous or
asynrchronous.
-- Decide to make output empty (we get an empty return or ack
right
away).
-- It's asynchronous in terms of the functionallity, not
the RPC.
* Successful meeting
- Mark to send out notes
- Andrew to clean up slides (like AbstractName -> WS-Name).
* Agenda for next week is to discuss the agreement document and also to = get
the minutes approved. This WG is on the agenda for the next steering group =
call next week. No expectations of problems. Expectation is for approval on
Tuesday.
------=_NextPart_000_0012_01C54BF3.9A259EA0
Content-Type: text/plain;
name="Minutes - 21 April 2005 - BES.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Minutes - 21 April 2005 - BES.txt"
OGSA BES BoF Telecon (21 April 2005)
Attendees
---------------
Mark Morgan (Minutes)
Fred Maciel
Hiro Kishimoto
Andrew Grimshaw
Steven Newhouse
Darren Pulsipher
Kabushige (NAREGI)
Ravi Harei
Tom McGuire
Chris Smith
Karl Czajkowski
Dave Snelling
Jem Treadwell
Agenda Bashing
------------------------
* Get Charter Finalized
* If we get through that, the future telecon schedule and the timeline
Some things we could knock off the list of future discussions
Finalize Charter
-----------------------
* Two modification that have been made to this document vs. the one that
was sent out before GGF13 in Korea
- Scoping
-- Only legacy, or service instantiation too
- Do we want to define what the interface is on the things that
get
returned from instantiation
- Stronger wording for communicating and interactinvg with the
OGSA WG
reguarlly
* Solicit a Volunteer to maintain the GridForge Site -- no volunteers.
* Andrew added sentence about OGSA-WG interaction.
* Need stronger language like Data and ByteIO -- like review meeting at
every milestone before the document is sent out.
- Will this slow us down?
- Having a review meeting is OK, but the question is do we need
blessing, or is this just a presentation.
* Does it hurt to have a review meeting?
* Will OGSA have a veto power?
- No, you can publish without, but if you want to use the ogsa
name,
then you have to have approval.
* We linked into the charter that we are going to be working along the
lines of the OGSA-WG -- why do we need a second ratification?
- The thing is, the charter talks about the spirit of these two
WGs,
but in the final analysis the two WG could have a
diametrically
opposed view and it would be up to the GFSG editor to sort it
out.
- Because of this, we're perfectly comfortable with this.
- Some have said that the current language is fine as it is as
long as
it is understood that the language doesn't mean veto.
- The GGF rules say that the OGSA WG does NOT have veto power.
- If one WG starts having veto power over another, then that has
to
come from somewhere.
* Scope
- Changed one thing in the initial scope doc....should it be
just for
legacy job management or for also web service intsantiation
management?
-- A number of people said that we shouldn't limit it.
-- Can view legacy job as a special case.
-- A lot of systems that have been discussed are the
same whether
or not the thing being launched is a legacy job.
-- Decision to allow for the general case.
* Goals
- Having a draft recommendation document by GGF14.
-- This is aggressive, but think we can do that.
-- Hoping we can refer to a bunch of stuff in JSDL.
- Not sure how well JSDL will cover service instantiation.
-- JSDL has the concept of being able to add any type of
service.
-- Either it will end up being that we will have to add
some
extensibilities on JSDL, or we will provide feedback
to the JSDL
group on things we need.
- Intention at UVa is to do an implementation of the spec. so
that we
can write an experience document for Sept.
-- We need that before we can push the doc. all the way
through.
- The next deadline is can we have fought out all the details by
Nov in
order to get a public document out.
- We don't want to say that the doc. in June is a proposed
standard,
but we do want to make it publically available.
-- It will be a publically available working group
draft.
- What about the Experience Doc.
-- Not clear from the process how we should handle this.
-- Assuming we do one at UVa, we will write up our
experience with
that, since it's info doc, we could bring it to the
WG, then
they could decided whether or not to make it a WG
info doc.
-- OMII is aiming to also have an implementation. So
supposedly
we'd have the real document for the GGF editor and
for review
in the end of October.
* Management Issues
- It's boiler plate for the steering committee.
- Platform is agreeing to praticipate at some level.
* OGSA is very focused on interoperability issues, this is why the
Base Profile is so important. Not only OGSA WG but aslo GFSG wants to
see ogsa prefixed wg like this is based on the basic profile or not.
What does this working group think about the Basic Profile.
- Andrew frames question this way: There may in the end be
several
basic profiles.
- What he would rather have the working group focus on is the
issues
such as "What are the interfaces", "What are the attributes or
meta
data that are relevant" as opposed to the particular mechanics
that
are used to manipulate them.
- That said, take attributes (which could be Resource
Properties) -- We
can define them as attributes or meta data, but then say that
the way
that they would be rendered in the OGSA BP would be as
resource
properties. That way we don't close the door on others. It's
not as
strong as what you want to put in.
- But, if you don't define how you access informtaion and
capabilities,
then you don't have a complete interface. If you leave it
open, then
you throw interoperability out the window.
- Yes, you have to describe an access mechanism, but there is no
reason
you can't define multiple access mechanisms.
-- At least one should be based on Basic Profile. That
is fine.
- Everyone can agree that we might want a resource property for
a
container that is called "Processor Architecture" (like JSDL).
-- Clearly in a WSRF based impl, this would be a
resource property
that you can do a get on, but not a set. But, are we
going to
focus on what these properties are, but not how you
get them.
Can't we say, one way to get them is the WSRF way.
-- What we don't want to do is to proclude other ways of
doing
things in other ogsa profiles that may happen in the
future.
- When we put together the rough working group back in GGF 5.
Back
then we explicitly tied ourselvces to OGSI. That was a
mistake.
It seems very dangerous to have a technology option in the
charter.
But are we referencing a technology option (WSRF), or the
basic
profile which could change. Couldn't this change in the
future.
If there was a phrase about using a profile from the OGSA
working
group, then that's fine.
- On one of the last OGSA phone calls, we clarified that WSRF is
not
mandidated in the profile, but it does say that if you use
stateful
resources, then you use WSRF. But nothing says we have to
have
stateful resources. As long as the use of an OGSA profile is
in
here (and it's important to say "a" profile, not "the"
profile).
* This is in the charter now, everyone agrees with this.
* There are two levels of infrastructure defined
- WS-I base one
- WSRF on top of that.
- Clearly this is going to be a debate that will swing back and
forth
over time -- to a large extent, it's important for
interoperability.
- However, to hammer stuff out here at the beginning, it's OK.
Let's
define things in terms of the ideas, and then later we can
have a
"rendering" of the model with a specific technology.
- Some are skeptical of this -- seems like at the end of the day
we
really need to have WSDL.
-- Let's do everything in IDL right up front. Later we
can do the
mappings afterwords. Eventually we will need WSDL.
Not much agreement on this. IDL seems useful to some
people,
others would prefer to go straight to XML
-- Ultimately we need WSDL, but why can't we use IDL in
the
interim. But, is this discussion really necessary
wrt the
charter.
* We've asked to be called ogsa-bes, then if we think we are rendering
the
ogsa architecture, then we should reference the ogsa documents in
this.
- If this is uncomfortable to some people, then we should drop
the ogsa
brand.
- What isn't clear is whether or not the ogsa brand is open or
closed
to alternative profiles.
- Many would rather keep the ogsa brand on the working group.
- The WSRF v. WS-Transfer battle will have to be fought in the
OGSA WG.
- Should we say that if other profiles come up, that we would
try to do
our best to render all available profiles?
-- Not quite everyone.
-- Seems like we don't need to put this in the charter.
* Seems like we can say that everyone agrees and we can send this into
the
steering committee.
* Also seems like we will be an SRM.
* Would like to hold telecons every week
* The WG chairs will put together an agenda before early next week to
get
comments.
* We'll have a telecon next Thursday.
* On the OGSA WG call on next Monday, Andreas will be giving a
presentation of the JSDL specification
* We might also want to take a look at the SAGA groups outputs.
- They have an API and they might be an endpoint consumer for
what we
put together.
* Daren, Steven and Andrew will put togheter an agenda for next week.
* Charter to go in this afternoon.
* Re: F2F in may. There has been a plan to have the F2F in conjunction
with the OGSA F2F on May 22nd in london at Imperial College.
- We'll work something out for a telecon bridge.
- We'll work something out for Karl.
------=_NextPart_000_0012_01C54BF3.9A259EA0--
More information about the ogsa-wg
mailing list