OGSA BES BoF Telecon (21 April 2005) Attendees --------------- Mark Morgan (Minutes) Fred Maciel Hiro Kishimoto Andrew Grimshaw Steven Newhouse Darren Pulsipher Kabushige (NAREGI) Hrabri Rajic 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.