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

Andre Merzky andre at merzky.net
Wed Aug 11 04:09:37 CDT 2010


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.
> >
> 



-- 
Nothing is ever easy.


More information about the saga-rg mailing list