- gridrpc-wg - lists.ogf.org

GridRPC and wikipedia
by Eddy Caron 25 Jan '12

25 Jan '12

Dear all, http://en.wikipedia.org/wiki/GridRPC the GridRPC wikipedia pages have received a couple of remarks ... It's a little bit hard to do less technical when we are involved on the standard. If you have some idea to improve it let me know or just do it! This article provides insufficient context for those unfamiliar with the subject. Please help improve the article with a good introductory style. (September 2011) This article may be too technical for most readers to understand. Please help improve this article to make it understandable to non-experts, without removing the technical details. The talk page may contain suggestions. (September 2011) Best regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf HDR ENS Lyon ENS Lyon - LIP - Projet GRAAL/Avalon 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.72.72.80.04 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

1 0

DIET 2.8 is available
by Eddy Caron 15 Nov '11

15 Nov '11

Dear all, Attend the DIET Special Event at SC'11 with ... the new release of DIET DIET 'SC11' Release 2.8 and tools are now available on the DIET Web Site: http://graal.ens-lyon.fr/DIET/download.html Visit INRIA booth #127 and SysFera booth #4211 at SC'11 1. What's new in DIET 'SC11' 2.8 ? ------------------------------------------------ * Features: - New forwarders: they do not need a configuration file anymore, and they can be started at any time. - CORBA calls are more robust: Two handlers for communication failures and transient exceptions have been added. - a new tool has been introduced: dietObjects. It mimics the behavior of nameclt, but restricted to DIET CORBA objects. - dietObjects also shows which object is managed by which forwarder (or through which forwarder an object is accessible). * Compilation - DIET now requires Boost to compile. - removed dependency towards libuuid, we now use Boost UUID instead - endianness is now managed with Boost - replaced usage of fnmatch by boost:regex - intermediary libraries are not installed anymore * Source code organization: - we now use a modified version of cpplint (http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py) for checking our code against our coding standards. - we removed all deprecated code and documentation: - JXTA: was used to build a multi-MA hierarchy using a P2P approach - DTM: the former data manager - JUXMEM: was a P2P data manager used in conjunction with DTM - FD: fault detector - FAST: performance evaluation plugin - TAU: a code profiler - old CVS headers have been removed and replaced by Doxygen headers - move FWorkflow.dtd from /etc to /usr/share/diet since it's application data (accordingly to FHS) * List of available packages - Debian 'Sid' - Fedora 16 - Fedora 15 * Bug Fix: - Forwarders now unregister themselves from omniNames when they are shut down properly. - Forwarders can be launched after any DIET element - To avoid problems when a file managed by DAGDA is modified outside DAGDA, we know compute the files sizes before any transfer. - Let CMake manage rpath. Thus, you need to explicitly set your LD_LIBRARY_PATH or DYLD_LIBRARY_PATH variable. 2. What's new in LogServices 'SC11' 2.8 ? ----------------------------------------------------------- * Features: - New forwarders: they do not need a configuration file anymore, and they can be started at any time. - CORBA calls are more robust: Two handlers for communication failures and transient exceptions have been added. * Source code organization: - we now use a modified version of cpplint (http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py) for checking our code against our coding standards. * List of available packages - Debian 'Sid' - Fedora 16 - Fedora 15 * Bug Fix: - Forwarders now unregister themselves from omniNames when they are shut down properly. - Forwarders can be launched after LogCentral or a tool. - Let CMake handle rpath Enjoy Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf HDR ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.72.72.80.04 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

1 0

Roadmap of the GridRPC WG.
by Hidemoto Nakada 21 Sep '11

21 Sep '11

All, We had WG session and tutorial sessions yesterday. During the session, we discussed about the roadmap of the WG, including possibility of immediate shutting down the WG. As the conclusion, we determined to continue the WG, and concentrate on a document that complements the data handle document which is approved this June. I understand that, - Yves Caniou will lead the effort, - we will have monthly Skype sessions starting in the middle of October, - and Eddy Caron will make call for participation for the Skype session using Doodle. cheers, -- HIDEMOTO NAKADA, Ph.D, AIST, Japan

2 2

Fwd: [wg-all] OGF33 CFP and Registration
by Hidemoto Nakada 20 Jul '11

20 Jul '11

All, I requested a session for GridRPC. See you there. -- HIDEMOTO NAKADA, Ph.D, AIST, Japan ---------- Forwarded message ---------- From: Joel Replogle <replogle(a)ogf.org> Date: Mon, Jul 18, 2011 at 8:12 AM Subject: [wg-all] OGF33 CFP and Registration To: wg-all(a)ogf.org OGF Community - OGF32 has just concluded in Salt Lake City, and now it's time to turn our attention to OGF33, quickly approaching on 19-23 September 2011 in Lyon, France. OGF is excited to be co-locating with the EGI Technical Forum as well as the IEEE Grid 2011 conference. Please make your requests for OGF33 sessions soon. Due to the timing and limited space available at the event, we are allocating session slots on a first-come, first-served basis. The OGF33 Call for Session Proposals is available at: http://www.ogf.org/OGF33/cfp.php Registration for the joint OGF33, EGI TF and IEEE 2011 event is open: http://www.ogf.org/OGF33/registration.php And the general event information is at http://www.ogf.org/OGF33/ Thanks, Joel -------------------------------------------------------------------- Joel Replogle Executive Director, OGF replogle(a)ogf.org http://www.ogf.org PO Box 1738 T: +1-765-228-9068 Muncie, IN 47308 USA F: +1-815-927-6284 Upcoming Events: OGF32 * July 15-18 * Salt Lake City, Utah USA * www.ogf.org/OGF32 OGF33 * September 19-23 * Lyon, France * www.ogf.org/OGF33 -- The wg-all mailing list is an umbrella list for all OGF mailing lists. If you are subscribed to any OGF mailing list, you will receive mails to wg-all. You can unsubscribe from this list on http://www.ogf.org/cgi-bin/perl/unsubscribe-wg-all.pl wg-all mailing list wg-all(a)ogf.org http://www.ogf.org/mailman/listinfo/wg-all

1 0

DIET 2.7 is available
by Eddy Caron 17 Jun '11

17 Jun '11

Dear all, DIET "LachaGore" Release 2.7 and tools are now available on DIET web site 1. What's new in DIET ? * Features: - A new traceLevel has appeared - A new method has been added to DIET_server.h: diet_get_SeD_services. Given the name of a SeD it returns the list of services of this SeD. - forwarders now find an unused port during initialization - a new API for administrating the DIET hierarchy has been created. * Compilation: - Documentation can now be compiled directly from the main CMakeLists.txt. - Documentation can though still be compiled separately from the doc directory. * Source code organization: - the old parser has been definitively removed - all elements of DIET apart from the dietForwarder now use macros in debug.hh to print out messages instead of using cout and cerr. - a new include file has been added: DIET_admin.h * Bug fix: - A few memory leaks - DIET elements do not hang anymore when a directory is given as a configuration file - Forwarder: really add all local addresses when using the "localhost" keyword in a reject or accept rule. - During initialization, if the POA already exists, then we now try to recover it instead of crashing. - SSH keys were not handled properly - async calls hanged when calling a profile with inout parameters - DAGDA: fixed bugs with paramstrings - New definition of FNM_CASEFOLD for AIX compatibility (AIX 5.1 or later) - DIET elements now correctly unsubscribe from omniNames 2. What's new in LogService ? - POA name has been changed to bidirLogService - SIGTERM and SIGINT can be used to properly shut down LogService Enjoy Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf HDR ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

1 0

GridRPC on wikipedia
by Eddy Caron 19 May '11

19 May '11

Dear Hidemoto, I created a basic wikipedia page for GridRPC http://en.wikipedia.org/wiki/GridRPC Now, Yves is working to improve this page. Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf HDR ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

2 1

Security Consideration section
by Eddy Caron 01 Apr '11

01 Apr '11

Dear all, Last step we must add a security consideration section as mentioned by Greg : > De : "Greg Newby" <newby(a)arsc.edu> > Date : 28 mars 2011 08:15:48 HAEC > À : Eddy Caron <Eddy.Caron(a)ens-lyon.fr> ... "Unfortunately nobody noticed earlier that you had not included a security considerations section. This is one of the requirements -- take a look at GFD #152 for discussion & example. I'm sorry for not pointing this out when the document was originally submitted." ... See www.ggf.org/documents/GFD.152.pdf for all information. I checked in the last SAGA-API document (because we are close to the behavior) and I propose the following update from the Andre's paragraph to be compliant to the GridRPC document. Security Considerations As the GRPC API is to be implemented on different types of Grid (and Cloud) middleware, it does not specify a single security model, but rather provides hooks to interface to various security models. A GRPC implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way. The implementations of advert services (the “backend” services to this API), need to take security concerns into account, because such a service might cause leaks of user (meta) data beyond the runtime of the applications using this API. This is the same risk as with storage and file systems, to which the GRPC Data Management core API provides an API. Unlike with established file systems, however, the risks associated with advert services might be less obvious to their implementors. Andre can I use your text as based ? No strong copyright on it ? :-) If someone from the GridRPC-WG have some remarks, constraints or additional information, let me know or update the CVS. Best Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

3 2

GRPC_STICKY vs GRPC_PERSISTENT
by Eddy Caron 26 Mar '11

26 Mar '11

Dear Daniel, After discussions, we have improved the definition of GRPC_STICKY. Definitions are now: – GRPC STICKY: used when a data is kept inside the platform but cannot be moved between the servers, except if the user explicitly ask for the migration. This is used if the client needs that data in the platform for a second computation on the same server for example. Note that in this case, the data can also be replicated and that potential coherency issues may arise. – GRPC PERSISTENT: used when a data has to be kept inside the platform. The underlying data middleware is explicitly asked to handle the data: the data can migrate or be replicated between servers depending on scheduling decisions, and potential coherency issues may arise if the user attempt to modify the data on his own. With you external point of view, do you think it's more clear and enough ? Thanks you for your feedback. Best Regards Yves and Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

3 3

Re: [GRIDRPC-WG] GridRPC document (Re: [wg-all] New documents published)
by Eddy Caron 23 Mar '11

23 Mar '11

Dear all, We have checked with Dan and indeed Greg didn't send the last document. I did it. Nevertheless the remark about the Persitent and Sticky still true. From my point of view: GRPC_Persitent means that the data is available in the platform. This data can move. Thus the middleware should manage this data as asked page 6 of the standard "The underlying data middleware is explicitly asked to handle the data" (I'm agree with that, I don't see another other way). GRPC_STICKY means that the data is available and can not move ! I found nothing in the document that explains that the data must be handle by the user (and it's sound good for me). From my point of view GRPC_STICKY is handle by the user or by the middleware. It depends on the implementation. I agree with Yves but somewhere, I am a little bit confuse if a data mode implies a behavior rule of the middleware usage. If I want to have a Sticky data somewhere but I don't care about where. I don't give the target of the data (the middleware will do it) or if I give both informations target and sticky mode then I manage myself the data. No ? Eddy Regards, Le 23 mars 2011 à 10:26, Yves Caniou a écrit : > Hello, > > Not rude remarks here, but I'm a bit confused: it seems that Dan read an old > version of the document? > - I can't find the typo in the URI > - I can't find the "To discuss:" that he's talking about. But it reminds me of > the paragraph that I put there from the beginning concerning the diffusion of > a data on the servers (Broadcast, multicast, and such things that were > available in OmniStorage)... > > BUT, concerning the distinction between GRPC_Persistent and GRPC_Sticky: > if we have to emphasize that the second one is when the user completely relies > on the data manager on the opposite of the second one where he manages > himself the data, can't we have a data managed by the underlying data manager > (transparent transfer) with some particularities (like if making the data > sticky or unique if the DM wants to migrate the data)? > > Cheers. > > .Yves. > > Le Wednesday 23 March 2011 02:26:15 Eddy Caron, vous avez écrit : >> Dear all, >> >> We have received the final comment from Dan. With Yves we will update the >> document to take into account these comments. >> >> Best Regards, >> Eddy >> >> Début du message réexpédié : >>> De : "Daniel S. Katz" <dsk(a)ci.uchicago.edu> >>> Date : 22 mars 2011 11:21:57 UTC+08:00 >>> À : Greg Newby <newby(a)arsc.edu> >>> Cc : Eddy Caron <Eddy.Caron(a)ens-lyon.fr>, Alan Sill <Alan.Sill(a)ttu.edu>, >>> Wolfgang Ziegler <Wolfgang.Ziegler(a)scai.fraunhofer.de> Objet : Rép : >>> GridRPC document (Re: [wg-all] New documents published) >>> >>> Hi, >>> >>> I think it generally looks fine, and the GrdiRPC session today was >>> helpful. Some specific issues I have: >>> >>> On page 6, the distinction between GRPC_Persistent and GRPC_Sticky is not >>> clear. >>> >>> On page 7, "“http://myName:/myhome/data/matrix1”" has an extra ":" in the >>> middle. >>> >>> On page 11, the items under "to discuss:" are confusing. It seems like >>> these should be resolved at this point, or marked as potential >>> extensions. Also, in the second item, the "on" should be "one". >>> >>> Dan >>> >>> -- >>> Daniel S. Katz >>> University of Chicago >>> (773) 834-7186 (voice) >>> (773) 834-3700 (fax) >>> d.katz(a)ieee.org or dsk(a)ci.uchicago.edu >>> http://www.ci.uchicago.edu/~dsk/ >> >> --------------------------------------------------------------------------- >> ------------------- Eddy Caron. Mcf ENS Lyon >> ENS Lyon - LIP - Projet GRAAL >> 46 Allee d'Italie, 69364 Lyon Cedex 07, France >> E-Mail : Eddy.Caron(a)ens-lyon.fr >> [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] >> --------------------------------------------------------------------------- >> --------------------- > > > > -- > Yves Caniou > Associate Professor at Université Lyon 1, > Member of the team project INRIA GRAAL in the LIP ENS-Lyon, > Délégation CNRS in Japan French Laboratory of Informatics (JFLI), > * in Information Technology Center, The University of Tokyo, > 2-11-16 Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan > tel: +81-3-5841-0540 > * in National Institute of Informatics > 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan > tel: +81-3-4212-2412 > http://graal.ens-lyon.fr/~ycaniou/ ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

2 1

Talk Material of OGF'31 is available on the GridForge
by Eddy Caron 22 Mar '11

22 Mar '11

Dear all, In live from the OGF'31 GridRPC session at Taipei. https://forge.gridforum.org/sf/docman/do/listDocuments/projects.gridrpc-wg/… Best Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

2 1