[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