[SAGA-RG] OGF 19 SAGA Minutes

[Pascal Kleijer]

Dear all,

Here is the first batch of minutes for the SAGA sessions we had at OGF 19.

BR,
Pascal Kleijer
k-pasukaru at ap.jp.nec.com
-------------- next part --------------
SAGA - Public Comments
Sunflower: 14:00-15:30 Monday 29th January 2007
Goal: Overview of the public comments made on the API.

[AD] Workshop and All Hands-On presentation.

Q: Can we have an overview of the API?
A: Two persons request it. The presentation is shifted to the next SAGA session.

Overview of Kaiser's Comments.

Overview of Kleijer's Comments.
Discussion on the state machine and "Unknown" state. Language binding might have additional information about how the state is used.

Usage of Proxy Gates for streams. The consensus is to let it to the language binding and not within the API. Another mechanism has to be used.

Overview of Illingworth's Comments.

Overview of Pipan's Comments.
Q: Life time of the default session. How do we handle it?  
A: Get created as needed, gets destroyed on application shutdown.

Q: What is the purpose of adding a task to task_container more than once?
A: Nothing presents it.

Q: What happen when 3 files copy on the same job is done?
A: Depends on the implementation and how the job is handled on the back-end. 

Conclusion:
A task can only be added once to a container. The "add" will be silently ignored if added more then once.

Q: Discussion on the error handling and error list vs. single error messages. 
A: No we should stay as is now.

Q: Should the automatic conversion of a string to an array be there?
A: To simplify the API no, the conversion to list or arrays should not be automatic.

Q: Byte ordering important?
A: We have only streams of bytes and files of bytes, thus no problem.
TODO: Ensures that the API properly state that we have stream of bytes and file of bytes.

Problem of having the attribute interface not supporting the asynchronous interface. The case is replica management where attribute are stored on the back-end.
Conclusion: The attribute interface will implement the asynchronous interface. (This is ugly but necessary).

Q: Should SAGA add a byte buffer class to handle streams, files, messages etc?
A: Yes, the API should be changed to support only bytes and add a Byte Buffer class.

API final submission for OGF 20. The document will be submitted end of March 2007.

What to submit:
- Clean New
- Commented New
- Change Log

Session Close: 15:25
%
-------------- next part --------------
SAGA - Extensions I
Azalea: 9:00-10:30 Tuesday 30th January 2007
Goal: C++ Language Bindings & API Extensions

Introduction of the C++ language bindings. Uses TR1 (currently Boost).

Q: Is the usage of TR1 (Boost) a good idea?
A: Yes this is standardized and supported by most compilers. The C/C++ community largely accepts this model.

Q: Do we shutdown some user base with this?
A: gcc 4 or more compilers should support it. Boost implementation is tested on many platforms everyday to ensure compatibility so TR1 should be fine.

TODO: List the possible architecture to see if TR1 is available. Post on the mailing list and give a 2 month deadline.

Q: Is the usage of templates good?
A: Yes since this is the most clean and simple way to do in C++.
TODO: Put in the mailing list to see if this is a good choice.

TODO: Create a list of header files for SAGA to define a core L&F for C++ like in Java. Combine this into a language binding document for OGF.
TODO: Create an entry in CVS for the C++ binding.

Introduction of the Messaging API (Andre).

Q: Is the topology approach useful and simple enough to support the 80/20 rule?
A: Yes but it is build on top of the streams API and ensure to support the needs of the different use cases.

Q: Are the labels for reliability correct?
A: They might not be the best, subject to be changed.

Q: The flags cannot be changed over time?
A: No, this might introduce to complex implementation and undefined states if the connections are already setup.

Q: Is the message class "manage" flag good?
A: In terms of C++ no, we better have another scheme. Consider to define in the language binding.

Q: Is this API not like MPI?
A: Yes MPI can be one implementation.

Q: Could we not dig into the use cases to set a list of usages and submit it to the MPI folk?
A: Yes this is a good idea.

It would be good to see how MPI does the messaging and take some of the syntax from it. TODO: Andre will tackle this and see how MPI did it and map it back to the proposal.

Other groups in OGF are working on some sort of message communication. Synchronization is necessary and planned.

TODO: The package name might not be good enough, seek a new name.
TODO: See what is different from MPI and list them.

Session Closed: 10:30
%
-------------- next part --------------
SAGA - Extensions II
Azalea: 11:00-12:30 Tuesday 30th January 2007
Goal: API Extensions

Steve Fisher, presentation about service discovery API. Work based on GLUE.

Q: Is this API useful for SAGA?
A: Yes, it can nicely fill in some gaps in the current API.

Q: Is SQL really the best choice? SAGA uses REGEX.
A: Yes since the information is based on key-value pairs and the queries can be rather complex that REGEX cannot properly express.

Q: How do we know where the endpoints are?
A: This must be exchanged before hand at some point to enable the communication.

Q: Can the API be extended to resource discovery?
A: This has been discussed. Basically yes, the resources can be attached to a service. Each resource has a unique identifier attached to a service thus backtracking of the service can be done based on the resource id.

TODO; Sit off-line to define the document draft. Add use cases and requirements in one document. Target OGF 20 for deadline.

CPR presentation.
Quick presentation and history of CPR. 
Overview of CPR requirements.
Presentation of the API. Build on the CORE API, based on job and namespace.

Q: How to address the blotting of checkpoint files?
A: There are some ideas but no concrete solution to handle this. The policy of checkpoint file life time has to be addressed but might be out of scope of SAGA.

Information Service
Present the idea of the information service and some usage of the approach.
Q: How does the API looks like?
A: Show the SAGA namespace API as base. The API would be build on top of the namespace.

Q: Should SAGA stick to REGEX or move to SQL?
A: No consensus on what is better.

Write down some code example of IS usage.

Session Closed: 12:30
%