[SAGA-RG] planning for OGF-30 interop demo

Yutaka Kawai yutaka.kawai at kek.jp
Mon Sep 13 20:37:15 CDT 2010


Dear Andre,

OGF-30 is coming next month. Can you let us know the status of the demo 
plan? We need to prepare for that.

 > IMHO, iRods would be an excellent OGF demo backend, given the
 > consistent and strong OGF participation of the iRods developers and
 > users!

The prototype of the irods replica adaptor will be available by then.

Best regards,
Yutaka


Yutaka Kawai  河井 裕
High Energy Accelerator Research Organization (KEK)
Computing Research Center
Tel: +81-(0)29-864-5200 (Ext: 4503)
Fax: +81-(0)29-864-4402
E-Mail : yutaka.kawai at kek.jp

(2010/08/11 18:09), Andre Merzky wrote:
> Quoting [Yutaka Kawai] (Aug 11 2010):
>>
>> Dear Andre,
>>
>>>>  From the top of my head, I would think that the following parties
>>> might be interested to team up resources (endpoints, code, people)
>>> to get things in place:
>>>
>>>     - VU Amsterdam
>>>     - IN2P3, France
>>>     - CCT, LSU
>>>     - KEK/Naregi
>>>     - RAL, UK
>>
>> OK for KEK to use NAREGI. However,
>>
>>> A simple interop demo would be to submit the same job (NOT
>>> /bin/date) to a set of resources in the various infrastructures
>>> discovered via SD, from various tools.  A job submitted via python
>>> for example should be monitorable from C++ tools, and output could
>>> be reaped via PySAGA-over-JSAGA, etc.
>>
>> Using SD to discover NAREGI resources will be difficult at the demo.
>> Certainly, we are developing SD adaptor for NAREGI now but the
>> development and test cannot be completed by that time. In my
>> understanding, SAGA has a prototype SD adaptor only for glite at this
>> moment. Do you know how about other middlewares?
>
> I do not know about any other sd adaptor.  However, we do have a
> default adaptor in saga-core, which, at the moment, does nothing.
> We shouod certainly be able to extend that one to read service
> locations from a config file.  Together with the gLite adaptor that
> should provide all we need for the demo.
>
> Hartmut, is that something you could take on?
>
>
>
>>>      Replica Management (not JSAGA?)
>>>>
>> JSAGA supports Replica Management package for gLite-LFC, iRODS and SRB.
>>
>> Great. Andre, Sylvain already has an iRODS replica adaptor for their
>> JSAGA. Do you still need that adaptor for SAGA C++ at the demo? If so,
>> we will try to complete the adaptor by then.
>
> IMHO, iRods would be an excellent OGF demo backend, given the
> consistent and strong OGF participation of the iRods developers and
> users!
>
> Best, Andre.
>
>
>> Best regards,
>> Yutaka
>>
>>
>> Yutaka Kawai  ?????? ???
>> High Energy Accelerator Research Organization (KEK)
>> Computing Research Center
>> Tel: +81-(0)29-864-5200 (Ext: 4503)
>> Fax: +81-(0)29-864-4402
>> E-Mail : yutaka.kawai at kek.jp
>>
>> (2010/08/09 18:44), Andre Merzky wrote:
>>> Hi all,
>>>
>>> as most of you should now by now, we plan a SAGA interop demo for
>>> OGF30 in Brussels (http://www.ogf.org/OGF30/).  In order to pull
>>> that off successfully, we need to start to define
>>>
>>>    - participants
>>>    - scope
>>>    - implementations to be used
>>>    - interop demo scenario
>>>
>>> > From the top of my head, I would think that the following parties
>>> might be interested to team up resources (endpoints, code, people)
>>> to get things in place:
>>>
>>>    - VU Amsterdam
>>>    - IN2P3, France
>>>    - CCT, LSU
>>>    - KEK/Naregi
>>>    - RAL, UK
>>>
>>> It would be great if each party could let us know explicitely if
>>> they are interested in participating!  Did I miss anybody?
>>>
>>> We have the following bits and pieces which may, or may not, play a
>>> role in the interop demo
>>>
>>>    implementations:
>>>      JavaSAGA
>>>      JSAGA
>>>      SAGA-C++
>>>      PySAGA (over JavaSAGA)
>>>      PySAGA (over JSAGA)
>>>      SAGA-Python (over SAGA-C++)
>>>      command line tools for most of the implementations
>>>
>>>    functionality:
>>>      Job Submission (all)
>>>      Data transfer / access (all)
>>>      Advert Service (not JSAGA I think, not in PySAGA)
>>>      Replica Management (not JSAGA?)
>>>      Service Discovert (not in JSAGA?  not in PySAGA)
>>>
>>>    backends:
>>>      local  (all)
>>>      globus (all)
>>>      ssh    (all)
>>>      aws    (all?)
>>>      glite  (all?)
>>>      bes    (all?)
>>>
>>>    Infrastructures
>>>      local institutions
>>>      teragrid
>>>      loni
>>>      naregi
>>>      What about European Grids?
>>>
>>>
>>> Again, is there something I miss?
>>>
>>> PySAGA appears to be a great integration point, and SAGA-C++ intents
>>> to support it very soon, too - but it is not sure that we manage to
>>> do that before OGF30.
>>>
>>> A simple interop demo would be to submit the same job (NOT
>>> /bin/date) to a set of resources in the various infrastructures
>>> discovered via SD, from various tools.  A job submitted via python
>>> for example should be monitorable from C++ tools, and output could
>>> be reaped via PySAGA-over-JSAGA, etc.
>>>
>>> The above is just an initial input, to get the discussion and
>>> planning started.  Please feed back, and complete the item lists
>>> above.  Once we have those lists complete, we should be able to come
>>> up with some more or less realistic scenario.
>>>
>>> I'll mirror thiss list on our wiki at GridForge, so that we can edit
>>> things in place.  Feel free to discuss on the list though, I'll try
>>> to keep the thread in sytnc with the wiki.
>>>
>>> Best, Andre.
>>>
>>
>
>
>



More information about the saga-rg mailing list