Session: SAGA #1 Location: Exchange 2/3 Time: 14:00-15:30 Monday 7th May 2007 Administrative: --------------- Administrative Stuff and Agenda Overview: --------- Very quick and simple SAGA Overview. For a detailed presentation of SAGA the Wednesday presentation is the place. Q: JSDL, ByteIO, BES, Others supports? A: Should come up in the discussion today. Q: Java and other languages how do they deal with the SAGA definitions, i.e. SAGA streams against Java streams. A: This will be discussed during the language bindings part. Q: ARNS used for service discovery, how does SAGA deal with it? R: Will be treated later in the session. Security Model: --------------- Q: The current context model might end up into problems with all the possible solutions. A: No because we implement and base the work on the uses cases and don’t try to make an implementation that can do everything. Q: We should write down how to do handle/implement the context class. A: Yes but not in the SAGA code API document, must be in another document, i.e. "Best Practice". Q: Do you define the strings of the permission model? A: We define the available permissions as enum. We do not define the format of IDsm and know this is a weakness of the definition. The implementation must handle this issue. Q: Exception of the directory constructor does not permission denied? A: Yes this is an error. Q: Permission interface. Why "user" attribute? A: This should be "ID". Q: Recursive permission handling? A: Now we don’t have defined it yet. Other packages have it. We need to investigate if it is needed. Q: What does permission owner? A: The owner can change the permissions and is unique. Q: How are negative permissions handled? A: Difficult (in implementation) but it should be possible. Simple in API. Q: What have a group and user getter since the user is unique? A: The back end must know the notion of both and handle this issue. == We need to continue off-line the discussion on the permission model. Service Discovery: ------------------ Overview of the proposal. Q: In the get_glue() and get_data() the right way to go? A: postpone question. Q: Is the session handle a good idea? A: No that is the point, we are not sure. TODO: Steve to finalise, last call on list, then to editor Presentation of Genesis II. Session: SAGA #2 Location: Exchange 2/3 Time: 16:00-17:30 Monday 7th May 2007 Service Discovery (ii): ----------------------- Demo of the Serviced Discovery Implementation. Uses LDAP in the back end. Q: Why "RunningJobs" and not "nJobs"? A: That depends on the implementation and the syntax defined by the provider. Q: If SAGA goes for its own key set, does it matter? A: No problem, their just need to be a keymapper. Q: Glue parameters are exposed in the demo. Is that necessary? A: This demo dumps it as is, but we could hide the glue attributes. Also not all glue attributes are pertinent for service discovery, the implementation should be smarter and prune out unnecessary attributes. Q: Is the VO field necessary since we can have a context? A: Not mandatory since the implementation can lookup the VO from the context and scale down the output directly. Q: In the get_glue() and get_data() the right way to go? A: Yes it is a solution if not the most elegant. Discussion for the need of the glue distinction. Yes since the glue attributes names are not fixed yet and the names might clash with service attributes. CPR: ---- State of the group is: dead. The architecture doc is out of date and fixing it out of scope for the SAGA groups. The API is good enough to be integrated into SAGA without much effort. The OGF editor accepts to publish to document "as is" even if the content is mostly putdated. Thilo will look in the architecture document and see what can be done for the document. Edinburgh is the target deadline for decide what to do. Task Model: ----------- Show the old and new Task model proposal. The new model uses templates where the rest does not. Q: Is this a good choice? A: There seems to be no problems. Most seems to agree the new version seems better. Actions: - Post the new model on the ML for final call. - Request a comment from Chris Smith. Java Language Bindings: ----------------------- Add the stream based IO to the Java bindings. This is only for Java. Q: Is their a problem with it? A: No arguments against it. Actions: - Post the proposal on the ML. Q: Do we go Java 1.5, or newer as Java 1.5 is already 'legacy'? A: Java 1.5 should cover all the needs for SAGA, 1.6 has no feature that would help SAGA. Q: Is Java COG used? A: Yes it is used in the back end of the engine. JSDL Extension: --------------- There are two extensions to discuss. The details are pushed to the next session. Session: SAGA #3 Location: Exchange 2/3 Time: 18:00-19:30 Monday 7th May 2007 Adoption and Outreach --------------------- Q: UK eScience is OMII? A: Yes Q: Tutorial list does not mention summer schools? A: Yes we missed a couple but they are there. We did some in the NL and some others are planned. EGEE and middleware vendors need to be involved and support SAGA. Q: Does DEISA have any intent for a broader use of SAGA? A: Nothing concrete yet. Basically only what has been developed is used. Q: Any from EGEE? A: No one! Q: TeraGrid? A: No one! Q: NAREGI? A: Satoshi Matsuoka has interest in SAGA but resources are not avialble to do any development. There is potential in the project to use SAGA. Pascal Kleijer has some prototype and has a use case. Q: Vendor? How about Platform? A: (Chris Smith): If there is not driver behind, no implementation will be made. Platform needs a critical mass of people before starting support SAGA. Having a SAGA Open Source reference implementation is a must! People interested in SAGA: 1.Coming to read. 2.XXX 3.Implement the spec Q: Do we need to focus on a small user groups? A: Yes, basically we need to go out to each group and promote it to them. We need a 1 page explanation pamphlet of what SAGA is. This must be used as the promotion start point. Groups interested in SAGA: - DGrid - AstroGrid - OMII-UK - OMII-EU - CompuSteer - ... Q: How can OMII-UK get a user group use SAGA? A: There is interest but no one wants to rewrite their code against SAGA if they have already a running solution. Q: Is their a matrix showing what bindings on what middleware is available? A: No, not yet. TODO: Andre/Ole: create matrix on saga page Q: Where is the level bindings kick in? A: For Java, the whole stack must be in native Java, but other languages can be done as wrappers around C++. Q: Is SAGA no increasing the complexity of the application stack or the head ache of debugging if there is an issue? A: Well SAGA should fix the quality issues of the middleware. It should relive the end user of problems. Debugging may be a problem. PROPOSAL: allow tracing in implementations. PROPOSAL: The SAGA home page should have an overview of the landscape of what exists, what is planned and in what state. Session Closed: 19:30