[ogsa-wg] Telecon Minutes for OGSA BES (21 April 2005 and 28 April 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@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--