Promised document
Colleagues, Last week I promised to deliver a document for discussion tomorrow on how to use existing specification (and profiles on those specifications) to realize the requirements in the April 29 draft GES info document. Attached is a word file that sketches out the solution. The document is not intended to be published - it is to organize a discussion and give you insight into my proposed solution to the requirements. I have also carefully read the GES document and have a number of comments on that as well. I will be sending it later today or tomorrow. My comments on the GES are not necessary to understand the "realization" document. I also encourage you to read the ISV primer. Andrew
Andrew, Concerning the PGI Execution Service : Thank you very much for your 'GES Realization via Existing Specifications.doc' proposal, which targets 'as small a specification as possible and attempt to use existing specifications and mechanisms when it makes sense.' In order for your document to be really useful, we all have to carefully check if all 'existing specifications and mechanisms' referred by your document are : - compatible between each other, - really implementable, - at an affordable cost. In order to ease this checks, I propose below links for the 'existing specifications and mechanisms referred by your document', and I ask you to : - verify if my links are accurate, - provide the accurate links inside the next version of your document. WS-Addressing : http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ WS-Naming : http://www.ogf.org/documents/GFD.109.pdf OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf TO BE VERIFIED JSDL : http://www.ogf.org/documents/GFD.136.pdf OGSA-BES : ATTENTION, you are NOT referring to recommendation GDF.108, but on 17 April 2009, you sent us DRAFT v32 'ogsa-bes-v32.doc', and you are now referring to DRAFT v27, which has NO link inside http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-wg/d... Could we use DRAFT v38, which is Version 3 at http://forge.gridforum.org/sf/go/doc15062?nav=1 ? HPC-BP : http://www.ogf.org/documents/GFD.114.pdf HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf RNS : http://www.ogf.org/documents/GFD.101.pdf Thank you in advance. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Tue, 12 May 2009, Andrew Grimshaw wrote:
Colleagues,
Last week I promised to deliver a document for discussion tomorrow on how to use existing specification (and profiles on those specifications) to realize the requirements in the April 29 draft GES info document. Attached is a word file that sketches out the solution. The document is not intended to be published – it is to organize a discussion and give you insight into my proposed solution to the requirements.
I have also carefully read the GES document and have a number of comments on that as well. I will be sending it later today or tomorrow. My comments on the GES are not necessary to understand the “realization” document. I also encourage you to read the ISV primer.
Andrew
Hi Etienne, I personally think that the 'at an affordable cost' criteria that you are now adding is not really that relevant. Any new implementaion will cost you money.... David On 12/05/2009 19:23, "Etienne URBAH" <urbah@lal.in2p3.fr> wrote:
Andrew,
Concerning the PGI Execution Service :
Thank you very much for your 'GES Realization via Existing Specifications.doc' proposal, which targets 'as small a specification as possible and attempt to use existing specifications and mechanisms when it makes sense.'
In order for your document to be really useful, we all have to carefully check if all 'existing specifications and mechanisms' referred by your document are : - compatible between each other, - really implementable, - at an affordable cost.
In order to ease this checks, I propose below links for the 'existing specifications and mechanisms referred by your document', and I ask you to : - verify if my links are accurate, - provide the accurate links inside the next version of your document.
WS-Addressing : http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
WS-Naming : http://www.ogf.org/documents/GFD.109.pdf
OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf TO BE VERIFIED
JSDL : http://www.ogf.org/documents/GFD.136.pdf
OGSA-BES : ATTENTION, you are NOT referring to recommendation GDF.108, but on 17 April 2009, you sent us DRAFT v32 'ogsa-bes-v32.doc', and you are now referring to DRAFT v27, which has NO link inside http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-wg/d... man.root.current_drafts Could we use DRAFT v38, which is Version 3 at http://forge.gridforum.org/sf/go/doc15062?nav=1 ?
HPC-BP : http://www.ogf.org/documents/GFD.114.pdf
HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf
RNS : http://www.ogf.org/documents/GFD.101.pdf
Thank you in advance.
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Tue, 12 May 2009, Andrew Grimshaw wrote:
Colleagues,
Last week I promised to deliver a document for discussion tomorrow on how to use existing specification (and profiles on those specifications) to realize the requirements in the April 29 draft GES info document. Attached is a word file that sketches out the solution. The document is not intended to be published it is to organize a discussion and give you insight into my proposed solution to the requirements.
I have also carefully read the GES document and have a number of comments on that as well. I will be sending it later today or tomorrow. My comments on the GES are not necessary to understand the ³realization² document. I also encourage you to read the ISV primer.
Andrew
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
In order for your document to be really useful, we all have to carefully check if all 'existing specifications and mechanisms' referred by your document are : - compatible between each other, - really implementable, - at an affordable cost. Let's start with WS-Addressing. There are tons of WS-Addressing implementations out there. Most (all?) WS stacks implement it. The biggest question is whether 1.0 or 1.1. (I think I have the version right). There have been MANY interops with this just as OGF, since HPC-BP is based on this, as is ByteIO, BES, RNS, and many others. Just with the HPC-BP there have been over 10 interoperable implementations over the course of SC 08 and
Etienne, 09. Ditto for BES. With respect to the OGSA-BES specification. The 1.0 that is out there is GFD.108. The v27 document I was referring to is an earlier draft of the spec that had things in it that are exactly what was specified in the "requirements", specifically the "pending" state and an elucidation of the sub states. Most of the document versions of BES are available in gridforge, http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-wg/d ocman.root.current_drafts?_pagenum=1. 27 is not there, but 26 and 28 are, those three are all pretty similar. 27 is just the first one I opened on my hard-drive that had "pending". Further, I have had an implementation of BES as a homework in my graduate OS class. A simple implementation (e.g., fork/exec) is really pretty easy. ByteIO has also interop'd (if we can turn that into a word. See the experiences document. It too is about as easy a spec as you can imagine. It is basically a wrapper around POSIX files. The only think complicated about it is implementing the OPTIONAL attachments mechanism which is a performance optimization (using attachments to the SOAP messages avoids painfully slow XML serialization of data blocks). RNS there has been less interoperability, Sarnowska reported on an interop between Genesis II and SNARL/SABLE (RNS/ByteIO on top of glite logical files) at the last OGF. RNS is pretty easy. It is a table with two entries, a string "key" and an XML element that has an EPR and XML-any inside. Basically it supports insert, list, delete. It is a trivial port-type to implement. HPC-BP and HPC-FSE have been implemented and interop'd by a number of groups. HPC-BP over 10, FSE I have not counted, the WG co-chairs would be able to answer that better than me. We've implemented it, Platform has too, am not sure about gridSAM. JSDL has been implemented by anybody who has implemented BES (or HPC-BP). XML parsing is never for the faint of heart, but I had two undergraduate class projects that involved parsing JSDL documents ... how hard can it be? For all of these "at an affordable cost" is hard to quantify. I would say that a really good, robust to all sorts of failures, implementation of BES is the hardest Compatibility is always a challenge, that is why we have interoperability events. A
-----Original Message----- From: Etienne URBAH [mailto:urbah@lal.in2p3.fr] Sent: Tuesday, May 12, 2009 2:23 PM To: Andrew GRIMSHAW Cc: pgi-wg@ogf.org; lodygens@lal.in2p3.fr; edges-na3@mail.edges-grid.eu Subject: Re: PGI Execution Service - Realization via existing specifications
Andrew,
Concerning the PGI Execution Service :
Thank you very much for your 'GES Realization via Existing Specifications.doc' proposal, which targets 'as small a specification as possible and attempt to use existing specifications and mechanisms when it makes sense.'
In order for your document to be really useful, we all have to carefully check if all 'existing specifications and mechanisms' referred by your document are : - compatible between each other, - really implementable, - at an affordable cost.
In order to ease this checks, I propose below links for the 'existing specifications and mechanisms referred by your document', and I ask you to : - verify if my links are accurate, - provide the accurate links inside the next version of your document.
WS-Addressing : http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
WS-Naming : http://www.ogf.org/documents/GFD.109.pdf
OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf TO BE VERIFIED
JSDL : http://www.ogf.org/documents/GFD.136.pdf
OGSA-BES : ATTENTION, you are NOT referring to recommendation GDF.108, but on 17 April 2009, you sent us DRAFT v32 'ogsa-bes-v32.doc', and you are now referring to DRAFT v27, which has NO link inside http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes- wg/docman.root.current_drafts Could we use DRAFT v38, which is Version 3 at http://forge.gridforum.org/sf/go/doc15062?nav=1 ?
HPC-BP : http://www.ogf.org/documents/GFD.114.pdf
HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf
RNS : http://www.ogf.org/documents/GFD.101.pdf
Thank you in advance.
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Tue, 12 May 2009, Andrew Grimshaw wrote:
Colleagues,
Last week I promised to deliver a document for discussion tomorrow on how to use existing specification (and profiles on those specifications) to realize the requirements in the April 29 draft GES info document. Attached is a word file that sketches out the solution. The document is not intended to be published - it is to organize a discussion and give you insight into my proposed solution to the requirements.
I have also carefully read the GES document and have a number of comments on that as well. I will be sending it later today or tomorrow. My comments on the GES are not necessary to understand the "realization" document. I also encourage you to read the ISV primer.
Andrew
Andrew,
Concerning the PGI Execution Service :
Thank you very much for your precisions about issues of compatibility
and implementability, with interop examples. I hope that they will
permit the chairs to take the best decisions.
Still :
- For BES, official recommendation GDF.108 does NOT contain the
'Running:Stage-in' and 'Running:Stage-out' states.
So we have to decide which basis we take for BES :
- Either OFFICIAL recommendation GDF.108, which I suppose is the one
for which you mention existing implementations.
Then we would have to modify / upgrade / improve / extend /
profile it, in order to introduce the new states.
- Or a DRAFT already containing the necessary states (for example
v38, for which I have given a link), for which I am doubting there is
any existing implementation and interop test.
Then we would have to begin by validating this DRAFT thoroughly.
Can you give your position on this subject ?
- I understand RNS as 'syntactic sugar' very useful for the end user,
but belonging to a high level (presentation) layer.
Is RNS really required for implementing Execution Service inside
PGI, as belonging to a low level layer ?
- I am NOT entirely sure that the links which I have given for the
'existing specifications and mechanisms' are accurate. Can you check
them, and clearly validate them or correct them ?
Thank you in advance for your answers.
Best regards.
-----------------------------------------------------
Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
Bat 200 91898 ORSAY France
Tel: +33 1 64 46 84 87 Skype: etienne.urbah
Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr
-----------------------------------------------------
On Tue, 12 May 2009, Andrew Grimshaw wrote:
> Etienne,
>
>> In order for your document to be really useful, we all have to carefully
>> check if all 'existing specifications and mechanisms' referred by your
>> document are :
>> - compatible between each other,
>> - really implementable,
>> - at an affordable cost.
> Let's start with WS-Addressing. There are tons of WS-Addressing
> implementations out there. Most (all?) WS stacks implement it. The biggest
> question is whether 1.0 or 1.1. (I think I have the version right).
> There have been MANY interops with this just as OGF, since HPC-BP is based
> on this, as is ByteIO, BES, RNS, and many others. Just with the HPC-BP there
> have been over 10 interoperable implementations over the course of SC 08 and
> 09.
>
> Ditto for BES.
>
> With respect to the OGSA-BES specification. The 1.0 that is out there is
> GFD.108. The v27 document I was referring to is an earlier draft of the spec
> that had things in it that are exactly what was specified in the
> "requirements", specifically the "pending" state and an elucidation of the
> sub states. Most of the document versions of BES are available in gridforge,
> http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-wg/d
> ocman.root.current_drafts?_pagenum=1. 27 is not there, but 26 and 28 are,
> those three are all pretty similar. 27 is just the first one I opened on my
> hard-drive that had "pending".
>
> Further, I have had an implementation of BES as a homework in my graduate OS
> class. A simple implementation (e.g., fork/exec) is really pretty easy.
>
> ByteIO has also interop'd (if we can turn that into a word. See the
> experiences document. It too is about as easy a spec as you can imagine. It
> is basically a wrapper around POSIX files. The only think complicated about
> it is implementing the OPTIONAL attachments mechanism which is a performance
> optimization (using attachments to the SOAP messages avoids painfully slow
> XML serialization of data blocks).
>
> RNS there has been less interoperability, Sarnowska reported on an interop
> between Genesis II and SNARL/SABLE (RNS/ByteIO on top of glite logical
> files) at the last OGF. RNS is pretty easy. It is a table with two entries,
> a string "key" and an XML element that has an EPR and XML-any inside.
> Basically it supports insert, list, delete. It is a trivial port-type to
> implement.
>
> HPC-BP and HPC-FSE have been implemented and interop'd by a number of
> groups. HPC-BP over 10, FSE I have not counted, the WG co-chairs would be
> able to answer that better than me. We've implemented it, Platform has too,
> am not sure about gridSAM.
>
> JSDL has been implemented by anybody who has implemented BES (or HPC-BP).
> XML parsing is never for the faint of heart, but I had two undergraduate
> class projects that involved parsing JSDL documents ... how hard can it be?
>
> For all of these "at an affordable cost" is hard to quantify. I would say
> that a really good, robust to all sorts of failures, implementation of BES
> is the hardest
>
> Compatibility is always a challenge, that is why we have interoperability
> events.
>
>
> A
>
>> -----Original Message-----
>> From: Etienne URBAH [mailto:urbah@lal.in2p3.fr]
>> Sent: Tuesday, May 12, 2009 2:23 PM
>> To: Andrew GRIMSHAW
>> Cc: pgi-wg@ogf.org; lodygens@lal.in2p3.fr; edges-na3@mail.edges-grid.eu
>> Subject: Re: PGI Execution Service - Realization via existing
>> specifications
>>
>> Andrew,
>>
>> Concerning the PGI Execution Service :
>>
>> Thank you very much for your 'GES Realization via Existing
>> Specifications.doc' proposal, which targets 'as small a specification as
>> possible and attempt to use existing specifications and mechanisms when
>> it makes sense.'
>>
>> In order for your document to be really useful, we all have to carefully
>> check if all 'existing specifications and mechanisms' referred by your
>> document are :
>> - compatible between each other,
>> - really implementable,
>> - at an affordable cost.
>>
>> In order to ease this checks, I propose below links for the 'existing
>> specifications and mechanisms referred by your document', and I ask you
>> to :
>> - verify if my links are accurate,
>> - provide the accurate links inside the next version of your document.
>>
>> WS-Addressing :
>> http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
>>
>> WS-Naming : http://www.ogf.org/documents/GFD.109.pdf
>>
>> OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf
>> TO BE VERIFIED
>>
>> JSDL : http://www.ogf.org/documents/GFD.136.pdf
>>
>> OGSA-BES : ATTENTION, you are NOT referring to recommendation
>> GDF.108, but on 17 April 2009, you sent us DRAFT v32
>> 'ogsa-bes-v32.doc', and you are now referring to
>> DRAFT v27, which has NO link inside
>> http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-
>> wg/docman.root.current_drafts
>> Could we use DRAFT v38, which is Version 3 at
>> http://forge.gridforum.org/sf/go/doc15062?nav=1 ?
>>
>> HPC-BP : http://www.ogf.org/documents/GFD.114.pdf
>>
>> HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf
>>
>> RNS : http://www.ogf.org/documents/GFD.101.pdf
>>
>>
>> Thank you in advance.
>>
>> Best regards.
>>
>> -----------------------------------------------------
>> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS
>> Bat 200 91898 ORSAY France
>> Tel: +33 1 64 46 84 87 Skype: etienne.urbah
>> Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr
>> -----------------------------------------------------
>>
>>
>> On Tue, 12 May 2009, Andrew Grimshaw wrote:
>>> Colleagues,
>>>
>>> Last week I promised to deliver a document for discussion tomorrow on
>>> how to use existing specification (and profiles on those specifications)
>>> to realize the requirements in the April 29 draft GES info document.
>>> Attached is a word file that sketches out the solution. The document is
>>> not intended to be published - it is to organize a discussion and give
>>> you insight into my proposed solution to the requirements.
>>>
>>> I have also carefully read the GES document and have a number of
>>> comments on that as well. I will be sending it later today or tomorrow.
>>> My comments on the GES are not necessary to understand the "realization"
>>> document. I also encourage you to read the ISV primer.
>>>
>>> Andrew
>
>
>
- For BES, official recommendation GDF.108 does NOT contain the 'Running:Stage-in' and 'Running:Stage-out' states.
So we have to decide which basis we take for BES :
- Either OFFICIAL recommendation GDF.108, which I suppose is the one for which you mention existing implementations.
This should be the basis for any further work. Andrew circulated earlier versions just to show you relevant functions that were discussed that did not make it into the final version. Steven
All, The standard is the standard. That said what I was trying to point out was 1) That with minor updates to the BES spec, say to a 1.1 version we could accommodate many of the requirements in the GES document 2) That in fact the authors of the BES anticipated many of these same issues but that they were weeded out. As another note since it was perhaps not clear. I was NOT suggesting that sub-states become part of a new BES 1.1 specification - that "pending" perhaps should, and that we PROFILE the substates. Talk to you all in 130 minutes. A
-----Original Message----- From: Steven Newhouse [mailto:Steven.Newhouse@cern.ch] Sent: Wednesday, May 13, 2009 7:08 AM To: Etienne Urbah; Andrew GRIMSHAW Cc: pgi-wg@ogf.org; edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr Subject: RE: [Pgi-wg] PGI Execution Service - Realization via existingspecifications
- For BES, official recommendation GDF.108 does NOT contain the 'Running:Stage-in' and 'Running:Stage-out' states.
So we have to decide which basis we take for BES :
- Either OFFICIAL recommendation GDF.108, which I suppose is the one for which you mention existing implementations.
This should be the basis for any further work. Andrew circulated earlier versions just to show you relevant functions that were discussed that did not make it into the final version.
Steven
Hey PGI team, we are running in the pro/contra discussions again and again as it looks like... consuming our valuable time fosterings positions w/o clear understanding of the bigger picture. I suggest we clearly collect all statements related to pro/contra new / old specs inside the following wiki page tables: http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/GES?_mes sage=1242216401105 Let's try to collect all statements and positions and have an objective whole view on all of them together by filling out this page. I hope this also supports the telcon so thanks for adding your views to the tables. Your co-chair, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Andrew Grimshaw -Sent: Wednesday, May 13, 2009 1:48 PM -To: 'Steven Newhouse'; 'Etienne Urbah'; 'Andrew GRIMSHAW' -Cc: pgi-wg@ogf.org; edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr -Subject: Re: [Pgi-wg] PGI Execution Service - Realization viaexistingspecifications - -All, -The standard is the standard. - -That said what I was trying to point out was - 1) That with minor updates to the BES spec, say to a 1.1 version we -could accommodate many of the requirements in the GES document - 2) That in fact the authors of the BES anticipated many of these -same issues but that they were weeded out. - -As another note since it was perhaps not clear. I was NOT suggesting that -sub-states become part of a new BES 1.1 specification - that "pending" -perhaps should, and that we PROFILE the substates. - -Talk to you all in 130 minutes. - -A - -> -----Original Message----- -> From: Steven Newhouse [mailto:Steven.Newhouse@cern.ch] -> Sent: Wednesday, May 13, 2009 7:08 AM -> To: Etienne Urbah; Andrew GRIMSHAW -> Cc: pgi-wg@ogf.org; edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr -> Subject: RE: [Pgi-wg] PGI Execution Service - Realization via -> existingspecifications -> -> -> > - For BES, official recommendation GDF.108 does NOT contain the -> > 'Running:Stage-in' and 'Running:Stage-out' states. -> > -> > So we have to decide which basis we take for BES : -> > -> > - Either OFFICIAL recommendation GDF.108, which I suppose is the -> > one for which you mention existing implementations. -> -> This should be the basis for any further work. Andrew circulated earlier -> versions just to show you relevant functions that were discussed that -> did not make it into the final version. -> -> Steven - - -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
Dear Etienne, With your long list of "to-be-profiled" specifications that you collected from Andrew's proposal you made a very important point: The "composability" and "profilability" of these specs are not trivial at all. We saw that an entire OGF WG had to be set up just to synchronize the BES/JSDL (the HPC-BP group). And that process was slow and painful. Now we are talking about the extension/re-engineering of BES/JSDL AND the profiling of the new BES-1.2 JSDL-1.2 specs together with GLUE2 AND trying to make all these stuff satisfy the complex requirements around data staging. Plus add the other specs i did not mention here but you put into your list. The other alternative is to go for a clean spec. bye, Balazs Konya Etienne URBAH wrote:
Andrew,
Concerning the PGI Execution Service :
Thank you very much for your 'GES Realization via Existing Specifications.doc' proposal, which targets 'as small a specification as possible and attempt to use existing specifications and mechanisms when it makes sense.'
In order for your document to be really useful, we all have to carefully check if all 'existing specifications and mechanisms' referred by your document are : - compatible between each other, - really implementable, - at an affordable cost.
In order to ease this checks, I propose below links for the 'existing specifications and mechanisms referred by your document', and I ask you to : - verify if my links are accurate, - provide the accurate links inside the next version of your document.
WS-Addressing : http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
WS-Naming : http://www.ogf.org/documents/GFD.109.pdf
OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf TO BE VERIFIED
JSDL : http://www.ogf.org/documents/GFD.136.pdf
OGSA-BES : ATTENTION, you are NOT referring to recommendation GDF.108, but on 17 April 2009, you sent us DRAFT v32 'ogsa-bes-v32.doc', and you are now referring to DRAFT v27, which has NO link inside http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-wg/d...
Could we use DRAFT v38, which is Version 3 at http://forge.gridforum.org/sf/go/doc15062?nav=1 ?
HPC-BP : http://www.ogf.org/documents/GFD.114.pdf
HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf
RNS : http://www.ogf.org/documents/GFD.101.pdf
Thank you in advance.
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Tue, 12 May 2009, Andrew Grimshaw wrote:
Colleagues,
Last week I promised to deliver a document for discussion tomorrow on how to use existing specification (and profiles on those specifications) to realize the requirements in the April 29 draft GES info document. Attached is a word file that sketches out the solution. The document is not intended to be published – it is to organize a discussion and give you insight into my proposed solution to the requirements.
I have also carefully read the GES document and have a number of comments on that as well. I will be sending it later today or tomorrow. My comments on the GES are not necessary to understand the “realization” document. I also encourage you to read the ISV primer.
Andrew
-- Balázs Kónya NorduGrid Collaboration http://www.nordugrid.org Lund University balazs.konya@hep.lu.se High Energy Physics phone: +46 46 222 8049 BOX 118, S - 221 00 LUND, Sweden fax: +46 46 222 4015
Hi,
- The "composability" and "profilability" of these specs are not trivial at all.
I agree here that this too much modular approach - the "composability" - actually breaks significantly the interoperability, but if we profile (in PGI) what is mandatory of which specification, so this point could be solved. Nevertheless you are right: we having huge dependencies to a lot of specifications, while we have already problems with BES/GES, we even not entered the space of JSDL with much more specs and options... .. also the list from Andrew lists new specs where the most production middlewares have not much experience with (RNS, WS-Naming, etc.) - My initial thought about PGI was to take what was existing (also BES) and only profile/add minor elements. Although I see the requirement that those standards could handle, my question would be of how realistic an implementation would be if we go for a complete new setup...
-The other alternative is to go for a clean spec.
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Balazs Konya -Sent: Wednesday, May 20, 2009 11:01 AM -To: Etienne URBAH; pgi-wg@ogf.org -Cc: Andrew GRIMSHAW; edges-na3@mail.edges-grid.eu; lodygens@lal.in2p3.fr -Subject: Re: [Pgi-wg] PGI Execution Service - Realization viaexisting specifications - -Dear Etienne, - -With your long list of "to-be-profiled" specifications that you collected from -Andrew's proposal you made a very important point: - -The "composability" and "profilability" of these specs are not trivial at all. - -We saw that an entire OGF WG had to be set up just to synchronize the BES/JSDL -(the HPC-BP group). And that process was slow and painful. - -Now we are talking about the extension/re-engineering of BES/JSDL AND the -profiling of the new BES-1.2 JSDL-1.2 specs together with GLUE2 AND trying to -make all these stuff satisfy the complex requirements around data staging. -Plus add the other specs i did not mention here but you put into your
Maybe faster, but would have a lot of redundancies to other specs where we might just 'borrow' what they have already. I guess it's worth having another look on the PGI Wiki related to the different pro/cons (once gridforge is up again)... Hear you later, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender) list.
- -The other alternative is to go for a clean spec. - -bye, -Balazs Konya - -Etienne URBAH wrote: -> Andrew, -> -> Concerning the PGI Execution Service : -> -> Thank you very much for your 'GES Realization via Existing -> Specifications.doc' proposal, which targets 'as small a specification as -> possible and attempt to use existing specifications and mechanisms when -> it makes sense.' -> -> In order for your document to be really useful, we all have to carefully -> check if all 'existing specifications and mechanisms' referred by your -> document are : -> - compatible between each other, -> - really implementable, -> - at an affordable cost. -> -> In order to ease this checks, I propose below links for the 'existing -> specifications and mechanisms referred by your document', and I ask you -> to : -> - verify if my links are accurate, -> - provide the accurate links inside the next version of your document. -> -> WS-Addressing : -> http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ -> -> WS-Naming : http://www.ogf.org/documents/GFD.109.pdf -> -> OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf -> TO BE VERIFIED -> -> JSDL : http://www.ogf.org/documents/GFD.136.pdf -> -> OGSA-BES : ATTENTION, you are NOT referring to recommendation -> GDF.108, but on 17 April 2009, you sent us DRAFT v32 -> 'ogsa-bes-v32.doc', and you are now referring to -> DRAFT v27, which has NO link inside -> http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes- -wg/docman.root.current_drafts -> -> Could we use DRAFT v38, which is Version 3 at -> http://forge.gridforum.org/sf/go/doc15062?nav=1 ? -> -> HPC-BP : http://www.ogf.org/documents/GFD.114.pdf -> -> HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf -> -> RNS : http://www.ogf.org/documents/GFD.101.pdf -> -> -> Thank you in advance. -> -> Best regards. -> -> ----------------------------------------------------- -> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS -> Bat 200 91898 ORSAY France -> Tel: +33 1 64 46 84 87 Skype: etienne.urbah -> Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -> ----------------------------------------------------- -> -> -> On Tue, 12 May 2009, Andrew Grimshaw wrote: ->> Colleagues, ->> ->> Last week I promised to deliver a document for discussion tomorrow on ->> how to use existing specification (and profiles on those ->> specifications) to realize the requirements in the April 29 draft GES ->> info document. Attached is a word file that sketches out the solution. ->> The document is not intended to be published it is to organize a ->> discussion and give you insight into my proposed solution to the ->> requirements. ->> ->> I have also carefully read the GES document and have a number of ->> comments on that as well. I will be sending it later today or ->> tomorrow. My comments on the GES are not necessary to understand the ->> realization document. I also encourage you to read the ISV primer. ->> ->> Andrew - --- -Balázs Kónya - -NorduGrid Collaboration -http://www.nordugrid.org - -Lund University balazs.konya@hep.lu.se -High Energy Physics phone: +46 46 222 8049 -BOX 118, S - 221 00 LUND, Sweden fax: +46 46 222 4015 -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
All, I've just had the chance to catch up with my email and had not seen any comment to Andrew's document? Was this discussed on the call this week? What was the result... The distillation of the GES requirements document into a number of succinct points was very coherent! Is this list something that we can all agree on? What is missing if anything? If we all agree on these focused requirements we can then drill down into seeing how each individual component can be met from current specifications. If not then we have defined a clear case to profile or write additional specifications to fill these gaps. And we will have made some concrete progress towards our goal! Steven Dr Steven Newhouse EGEE Technical Director Contact Details: http://cern.ch/Steven.Newhouse <http://cern.ch/Steven.Newhouse> EGEE09 Conference 21-25 September, Barcelona - http://egee09.eu-egee.org/ Call for Sessions - http://indico.cern.ch/conferenceDisplay.py?confId=55893 <http://indico.cern.ch/conferenceDisplay.py?confId=55893> From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: 12 May 2009 16:06 To: pgi-wg@ogf.org Subject: [Pgi-wg] Promised document Colleagues, Last week I promised to deliver a document for discussion tomorrow on how to use existing specification (and profiles on those specifications) to realize the requirements in the April 29 draft GES info document. Attached is a word file that sketches out the solution. The document is not intended to be published - it is to organize a discussion and give you insight into my proposed solution to the requirements. I have also carefully read the GES document and have a number of comments on that as well. I will be sending it later today or tomorrow. My comments on the GES are not necessary to understand the "realization" document. I also encourage you to read the ISV primer. Andrew
Steven Newhouse wrote:
All,
I've just had the chance to catch up with my email and had not seen any comment to Andrew's document? Was this discussed on the call this week? What was the result...
The document has been discussed during the call, and at the moment there is no result yet. There are currently two positions within the PGI WG, one arguing that the best way to address the requirements is to write a new specification (taking the useful bits and pieces from BES/JSDL/whatever), and the other arguing that everything can be accomplished from existing specifications/profiles, plus additional profiling. No consensus has emerged so far on which is the direction to go. Apparently it is possible to achieve the requirements with both approaches, but this alone is not enough to suggest one of them over the other. As far as Andrew's document is concerned, I had a couple of comments but before making them I am skimming through the specs and profiles referenced therein so that I have a better understanding. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
Hi Moreno, I would consider that this is becoming a fundamental problem within the group. When it was setup it was certainly the impression of those that started off the discussions etc that it would be a profiling and current standards extension effort rather than all new standards... David On 15/05/2009 08:43, "Moreno Marzolla" <moreno.marzolla@pd.infn.it> wrote:
Steven Newhouse wrote:
All,
I've just had the chance to catch up with my email and had not seen any comment to Andrew's document? Was this discussed on the call this week? What was the result...
The document has been discussed during the call, and at the moment there is no result yet. There are currently two positions within the PGI WG, one arguing that the best way to address the requirements is to write a new specification (taking the useful bits and pieces from BES/JSDL/whatever), and the other arguing that everything can be accomplished from existing specifications/profiles, plus additional profiling.
No consensus has emerged so far on which is the direction to go. Apparently it is possible to achieve the requirements with both approaches, but this alone is not enough to suggest one of them over the other.
As far as Andrew's document is concerned, I had a couple of comments but before making them I am skimming through the specs and profiles referenced therein so that I have a better understanding.
Moreno.
David Wallom wrote:
Hi Moreno,
I would consider that this is becoming a fundamental problem within the group. When it was setup it was certainly the impression of those that started off the discussions etc that it would be a profiling and current standards extension effort rather than all new standards...
As far as I'm concerned, I have always been very careful to talk about "profiling and/or writing something new", as it was never said nor suggested that profiling was absolutely the way to go. I agree that this is a fundamental issue, and I'm concerned about any real possibility to reach an agreement. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
Hi All, Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required. David On 15/05/2009 09:19, "Moreno Marzolla" <moreno.marzolla@pd.infn.it> wrote:
David Wallom wrote:
Hi Moreno,
I would consider that this is becoming a fundamental problem within the group. When it was setup it was certainly the impression of those that started off the discussions etc that it would be a profiling and current standards extension effort rather than all new standards...
As far as I'm concerned, I have always been very careful to talk about "profiling and/or writing something new", as it was never said nor suggested that profiling was absolutely the way to go. I agree that this is a fundamental issue, and I'm concerned about any real possibility to reach an agreement.
Moreno.
David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required.
The requirements document is this one: http://forge.ogf.org/sf/go/doc15590?nav=1 (possibly with a better name). I suggest that any modification and improvement of the requirements should be done there. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
HI Moreno, Could we then have effort from Balazs, Morris or yourself to remove the "This needs text", "Further info needed" sections etc. Personally I prefer the extremely concise list within Andrews document. If we don't like that can we strip the Strawman (which it is not a requirements document) of extraneous text and get back to an explicit list of the requirements for specific components. David On 15/05/2009 11:20, "Moreno Marzolla" <moreno.marzolla@pd.infn.it> wrote:
David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required.
The requirements document is this one:
http://forge.ogf.org/sf/go/doc15590?nav=1
(possibly with a better name). I suggest that any modification and improvement of the requirements should be done there.
Moreno.
dear David, Steven, others David Wallom wrote: was [Pgi-wg] Promised document
HI Moreno,
Could we then have effort from Balazs, Morris or yourself to remove the "This needs text", "Further info needed" sections etc. Personally I prefer the extremely concise list within Andrews document. If we don't like that can we strip the Strawman (which it is not a requirements document) of extraneous text and get back to an explicit list of the requirements for specific components.
David
Steven wrote:
So what about Andrew's document? He has gone through and enumerated each requirement in a particular area... why would you not use this SHORT document to help determine where we have consensus and where we do not?
Steven
The group has been discussing the requirement document through quite some meetings. By now I consider the requirement document being accepted by the group. The document is THIS one: http://forge.ogf.org/sf/go/doc15590?nav=1 and not any kind of derivatives of it. The document is still a draft, it needs some further editing. Unfortunately, that editing work is pending because of the ever opening new discussion frontiers. I encourage everyone to send corrections related to the *original* requirement document. cheers, Balazs PGI co-chair
Hi Balazs, Great, would it be possible to include in it then the kind of summary (perhaps lifted from Andrews document) concise list of requirements. The current draft has areas where it is unclear and unfinished. Within requirements documents that I have had to code, design systems to (ESA) these concise derivatives have normally been put into a table with a clear naming structure etc so that when implementers/users have problems or issues they are able to easily say requirement A1 (for example) is unclear because of a, b, c d etc David On 20/05/2009 09:38, "Balazs Konya" <balazs.konya@hep.lu.se> wrote:
dear David, Steven, others
David Wallom wrote: was [Pgi-wg] Promised document
HI Moreno,
Could we then have effort from Balazs, Morris or yourself to remove the "This needs text", "Further info needed" sections etc. Personally I prefer the extremely concise list within Andrews document. If we don't like that can we strip the Strawman (which it is not a requirements document) of extraneous text and get back to an explicit list of the requirements for specific components.
David
Steven wrote:
So what about Andrew's document? He has gone through and enumerated each requirement in a particular area... why would you not use this SHORT document to help determine where we have consensus and where we do not?
Steven
The group has been discussing the requirement document through quite some meetings. By now I consider the requirement document being accepted by the group. The document is THIS one:
http://forge.ogf.org/sf/go/doc15590?nav=1
and not any kind of derivatives of it.
The document is still a draft, it needs some further editing. Unfortunately, that editing work is pending because of the ever opening new discussion frontiers.
I encourage everyone to send corrections related to the *original* requirement document.
cheers, Balazs PGI co-chair
Balazs, All, As I said in my email and comments on the 4/29 draft the GES strawman/requirements document has several places where it goes from requirements into specification, and where the requirements are quite vague. I sent those comments in embedded in the document. My listing of the requirements was not an attempt to replace the strawman document, but to distill the requirements from the prose. Without concise requirements it is difficult to move from requirements to specifications. A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Balazs Konya Sent: Wednesday, May 20, 2009 4:38 AM To: David Wallom; pgi-wg@ogf.org Cc: Steven Newhouse Subject: [Pgi-wg] requirement document
dear David, Steven, others
HI Moreno,
Could we then have effort from Balazs, Morris or yourself to remove the "This needs text", "Further info needed" sections etc. Personally I
the extremely concise list within Andrews document. If we don't like
David Wallom wrote: was [Pgi-wg] Promised document prefer that
can we strip the Strawman (which it is not a requirements document) of extraneous text and get back to an explicit list of the requirements for specific components.
David
Steven wrote:
So what about Andrew's document? He has gone through and enumerated each requirement in a particular area... why would you not use this SHORT document to help determine where we have consensus and where we do not?
Steven
The group has been discussing the requirement document through quite some meetings. By now I consider the requirement document being accepted by the group. The document is THIS one:
http://forge.ogf.org/sf/go/doc15590?nav=1
and not any kind of derivatives of it.
The document is still a draft, it needs some further editing. Unfortunately, that editing work is pending because of the ever opening new discussion frontiers.
I encourage everyone to send corrections related to the *original* requirement document.
cheers, Balazs PGI co-chair _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
hi Andrew, Andrew Grimshaw wrote:
Balazs, All,
As I said in my email and comments on the 4/29 draft the GES strawman/requirements document has several places where it goes from requirements into specification, and where the requirements are quite vague. I sent those comments in embedded in the document. My listing of the requirements was not an attempt to replace the strawman document, but to distill the requirements from the prose. Without concise requirements it is difficult to move from requirements to specifications.
indeed, your commented feedback is very helpful and now it is on our table to propagate your suggestions to the requirement draft. the draft is not completed at all, nevertheless on the phone conferences we seemed to develop an agreement about the requirements. Now we "just" have to write it down properly. I agree that the implementation parts should go away, those were initially added to help the better understanding of a certain requirement. all in all: there is more work to be done on the requirement strawman document. cheers, Balazs
The requirements document is this one:
http://forge.ogf.org/sf/go/doc15590?nav=1
(possibly with a better name). I suggest that any modification and improvement of the requirements should be done there.
So what about Andrew's document? He has gone through and enumerated each requirement in a particular area... why would you not use this SHORT document to help determine where we have consensus and where we do not? Why the reluctance on moving forward? Steven
On Friday 15 May 2009 13:10, David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required.
Is RNS requirement or implementation? A.K.
David
On 15/05/2009 09:19, "Moreno Marzolla" <moreno.marzolla@pd.infn.it> wrote:
David Wallom wrote:
Hi Moreno,
I would consider that this is becoming a fundamental problem within the group. When it was setup it was certainly the impression of those that started off the discussions etc that it would be a profiling and current standards extension effort rather than all new standards...
As far as I'm concerned, I have always been very careful to talk about "profiling and/or writing something new", as it was never said nor suggested that profiling was absolutely the way to go. I agree that this is a fundamental issue, and I'm concerned about any real possibility to reach an agreement.
Moreno.
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
Aleksandr, RNS is not a requirement. It shows up in my "GES Realization via Existing Specifications" as a means to meet the requirements. I personally think it is a good idea and allows us to work with an existing code base and access layer. Listing a directory of things is pretty common. A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Aleksandr Konstantinov Sent: Friday, May 15, 2009 9:32 AM To: pgi-wg@ogf.org Subject: Re: [Pgi-wg] Promised document
On Friday 15 May 2009 13:10, David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required.
Is RNS requirement or implementation?
A.K.
David
On 15/05/2009 09:19, "Moreno Marzolla" <moreno.marzolla@pd.infn.it>
wrote:
David Wallom wrote:
Hi Moreno,
I would consider that this is becoming a fundamental problem within
group. When it was setup it was certainly the impression of those
the that
started off the discussions etc that it would be a profiling and current standards extension effort rather than all new standards...
As far as I'm concerned, I have always been very careful to talk about "profiling and/or writing something new", as it was never said nor suggested that profiling was absolutely the way to go. I agree that this is a fundamental issue, and I'm concerned about any real possibility to reach an agreement.
Moreno.
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
On Friday 15 May 2009 16:54, Andrew Grimshaw wrote:
Aleksandr, RNS is not a requirement. It shows up in my "GES Realization via Existing Specifications" as a means to meet the requirements. I personally think it is a good idea and allows us to work with an existing code base and access layer. Listing a directory of things is pretty common.
Looks like a good idea for me (personally). I think You should make one more logical step and suggest to drop BES. No kidding. As You explained usage of RNS diring last telecon it can do anything BES does. One simply has to provide some data transmission capability to trasfer bigger chunks of data to/from nodes (not sure about term) presented by RNS. And that could be same ByteIO proposed by You or even simpler - HTTP(S) which is already used as underlying protocol of SOAP anyway. Actally we are using similar approach in ARC (production version) except that it uses GridFTP (and hence TVFS) instead of RNS. Concerning "work with an existing code" I'm not sure. I doubt many of participating projects have an implementation of RNS. And those developed probably won't be very reusable in different environment. Do You have an implementation for libxml2? On another hand AFAIR RNS is not a complex interface and wouldn't take much effort to implement. A.K.
A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Aleksandr Konstantinov Sent: Friday, May 15, 2009 9:32 AM To: pgi-wg@ogf.org Subject: Re: [Pgi-wg] Promised document
On Friday 15 May 2009 13:10, David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required.
Is RNS requirement or implementation?
A.K.
David
On 15/05/2009 09:19, "Moreno Marzolla" <moreno.marzolla@pd.infn.it>
wrote:
David Wallom wrote:
Hi Moreno,
I would consider that this is becoming a fundamental problem within
group. When it was setup it was certainly the impression of those
the that
started off the discussions etc that it would be a profiling and current standards extension effort rather than all new standards...
As far as I'm concerned, I have always been very careful to talk about "profiling and/or writing something new", as it was never said nor suggested that profiling was absolutely the way to go. I agree that this is a fundamental issue, and I'm concerned about any real possibility to reach an agreement.
Moreno.
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
David, Andrew, Aleksander and All, Concerning the document 'GES Realization via Existing Specifications' : I do NOT know if Aleksandr is kidding, but I agree with Andrew : RNS is NOT a requirement. Requirements are : - Compatible AUTHN credentials, and compatible AUTHZ credentials (covered in another thread, but NOT to be forgotten), - GLUE 2 to reference grid entities, - A well defined States and Transitions model (State Machine) for jobs, with precise semantics, - Some BES specification to define user operations on jobs, job states and job transitions, with precise semantics, - Some JSDL specification permitting the user to describe job requirements, data staging and job execution. I think that HPC-BP and HPC-BP FSE are useful recommendations permitting implementation, as described by Andrew, but I suppose that they are NOT requirements. I am quite sure that WS-Addressing and WS-Naming are NOT requirements, and I do NOT know at all how useful these specifications are for us. As I already wrote in my mail dated 13 May 2009, I understand RNS as 'syntactic sugar' very useful for the end user, but belonging to a higher level (presentation) layer, and NOT required for PGI. Finally, we need a diagram of dependencies between the different specifications which Andrew proposes. So I would ask : - David to send to the PGI mailing list the slides 26, 27 and 28 of the presentation 'Standardisation: Recent progress review and best-practices sharing: Middleware Track' which he performed at the 6th e-Infrastructure Concertation Meeting in Lyon on 24 November 2008 (or improved versions). - Andrew to present a diagram of dependencies between the different specifications he proposes, indicating which ones are really required. He can take as example the above mentioned slides. Thanks in advance to David and Andrew for their help. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Sat, 16 May 2009, Aleksandr Konstantinov wrote:
On Friday 15 May 2009 16:54, Andrew Grimshaw wrote:
Aleksandr, RNS is not a requirement. It shows up in my "GES Realization via Existing Specifications" as a means to meet the requirements. I personally think it is a good idea and allows us to work with an existing code base and access layer. Listing a directory of things is pretty common.
Looks like a good idea for me (personally). I think You should make one more logical step and suggest to drop BES. No kidding. As You explained usage of RNS diring last telecon it can do anything BES does. One simply has to provide some data transmission capability to trasfer bigger chunks of data to/from nodes (not sure about term) presented by RNS. And that could be same ByteIO proposed by You or even simpler - HTTP(S) which is already used as underlying protocol of SOAP anyway.
Actally we are using similar approach in ARC (production version) except that it uses GridFTP (and hence TVFS) instead of RNS.
Concerning "work with an existing code" I'm not sure. I doubt many of participating projects have an implementation of RNS. And those developed probably won't be very reusable in different environment. Do You have an implementation for libxml2? On another hand AFAIR RNS is not a complex interface and wouldn't take much effort to implement.
A.K.
A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Aleksandr Konstantinov Sent: Friday, May 15, 2009 9:32 AM To: pgi-wg@ogf.org Subject: Re: [Pgi-wg] Promised document
On Friday 15 May 2009 13:10, David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required. Is RNS requirement or implementation?
A.K.
David
Etienne et al, First, I will re-do the "realization" document based on comments and my own forgetfulness. With respect to Etienne's email, a few comments. You wrote
I am quite sure that WS-Addressing and WS-Naming are NOT requirements, and I do NOT know at all how useful these specifications are for us.
I agree about WS-Naming. But if we are going to use web services - then WS-Addressing is a must. WS-Addressing EPRs are how you "point" to web service endpoints.
As I already wrote in my mail dated 13 May 2009, I understand RNS as 'syntactic sugar' very useful for the end user, but belonging to a higher level (presentation) layer, and NOT required for PGI.
RNS is not presentation layer. It is naming layer that is human readable. RNS is simply the top layer in a classic three layer distributed systems naming scheme. We can argue about whether it is something we should use ... but we will end up using something like it no matter what, humans and XML were not meant for each other.
-----Original Message----- From: Etienne URBAH [mailto:urbah@lal.in2p3.fr] Sent: Tuesday, May 19, 2009 1:06 PM To: david.wallom@oerc.ox.ac.uk; Andrew GRIMSHAW; aleksandr.konstantinov@fys.uio.no; pgi-wg@ogf.org Cc: lodygens@lal.in2p3.fr; edges-na3@mail.edges-grid.eu Subject: Re: OGF PGI - Dependency diagram of existing specifications
David, Andrew, Aleksander and All,
Concerning the document 'GES Realization via Existing Specifications' :
I do NOT know if Aleksandr is kidding, but I agree with Andrew : RNS is NOT a requirement.
Requirements are :
- Compatible AUTHN credentials, and compatible AUTHZ credentials (covered in another thread, but NOT to be forgotten),
- GLUE 2 to reference grid entities,
- A well defined States and Transitions model (State Machine) for jobs, with precise semantics,
- Some BES specification to define user operations on jobs, job states and job transitions, with precise semantics,
- Some JSDL specification permitting the user to describe job requirements, data staging and job execution.
I think that HPC-BP and HPC-BP FSE are useful recommendations permitting implementation, as described by Andrew, but I suppose that they are NOT requirements.
I am quite sure that WS-Addressing and WS-Naming are NOT requirements, and I do NOT know at all how useful these specifications are for us.
As I already wrote in my mail dated 13 May 2009, I understand RNS as 'syntactic sugar' very useful for the end user, but belonging to a higher level (presentation) layer, and NOT required for PGI.
Finally, we need a diagram of dependencies between the different specifications which Andrew proposes. So I would ask :
- David to send to the PGI mailing list the slides 26, 27 and 28 of the presentation 'Standardisation: Recent progress review and best-practices sharing: Middleware Track' which he performed at the 6th e-Infrastructure Concertation Meeting in Lyon on 24 November 2008 (or improved versions).
- Andrew to present a diagram of dependencies between the different specifications he proposes, indicating which ones are really required. He can take as example the above mentioned slides.
Thanks in advance to David and Andrew for their help.
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
On Friday 15 May 2009 16:54, Andrew Grimshaw wrote:
Aleksandr, RNS is not a requirement. It shows up in my "GES Realization via Existing Specifications" as a means to meet the requirements. I personally think it is a good idea and allows us to work with an existing code base and access layer. Listing a directory of things is pretty common.
Looks like a good idea for me (personally). I think You should make one more logical step and suggest to drop BES. No kidding. As You explained usage of RNS
it can do anything BES does. One simply has to provide some data
capability to trasfer bigger chunks of data to/from nodes (not sure about term) presented by RNS. And that could be same ByteIO proposed by You or even simpler - HTTP(S) which is already used as underlying protocol of SOAP anyway.
Actally we are using similar approach in ARC (production version) except
GridFTP (and hence TVFS) instead of RNS.
Concerning "work with an existing code" I'm not sure. I doubt many of
projects have an implementation of RNS. And those developed probably won't be very reusable in different environment. Do You have an implementation for
On Sat, 16 May 2009, Aleksandr Konstantinov wrote: diring last telecon transmission that it uses participating libxml2?
On another hand AFAIR RNS is not a complex interface and wouldn't take much effort to implement.
A.K.
A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Aleksandr Konstantinov Sent: Friday, May 15, 2009 9:32 AM To: pgi-wg@ogf.org Subject: Re: [Pgi-wg] Promised document
On Friday 15 May 2009 13:10, David Wallom wrote:
Hi All,
Can we first agree (on the list, possibly with a doodle vote) that the requirements described in Andrews document were accurate. At this first stage please ignore the implementation, just are the requirements correct and if not what changes are required. Is RNS requirement or implementation?
A.K.
David
On Tue, 19 May 2009, Etienne URBAH wrote:
David, Andrew, Aleksander and All,
Concerning the document 'GES Realization via Existing Specifications' :
...
Finally, we need a diagram of dependencies between the different specifications which Andrew proposes. So I would ask :
- David to send to the PGI mailing list the slides 26, 27 and 28 of the presentation 'Standardisation: Recent progress review and best-practices sharing: Middleware Track' which he performed at the 6th e-Infrastructure Concertation Meeting in Lyon on 24 November 2008 (or improved versions).
- Andrew to present a diagram of dependencies between the different specifications he proposes, indicating which ones are really required. He can take as example the above mentioned slides.
The List of OGSA-BES et al. specifications (to be verified) is available at http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/GES Our EDGeS project would like to achieve interoperation by implementing as few specifications as possible. In particular : - Can David and Andrew confirm that practical interoperation does NOT require WS-RF, but only WS-I ? - Can Andrew precise which specifications depend on WS-RF, and which ones depend on RNS ?
Thanks in advance to David and Andrew for their help.
Best regards.
----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------
The document has been discussed during the call, and at the moment there is no result yet.
Why not? Ignoring (for now) how to implement the requirements was there agreement on the distillation of the requirements itself? There is a concrete list that the group could go through and agree/disagree on. Even if you identified which requirements you had consensus on or not that would be useful IMHO. Steven Dr Steven Newhouse EGEE Technical Director Contact Details: http://cern.ch/Steven.Newhouse EGEE09 Conference 21-25 September, Barcelona - http://egee09.eu-egee.org/ Call for Sessions - http://indico.cern.ch/conferenceDisplay.py?confId=55893
Steven Newhouse wrote:
The document has been discussed during the call, and at the moment there is no result yet.
Why not? Ignoring (for now) how to implement the requirements was there agreement on the distillation of the requirements itself?
Yes, there mostly was agreement on the requirements as nobody complained and the requirements document was discussed quite long before. There is a clarification needed regarding what is meant by "support for parallel jobs" in the requirements document, and furthermore it is still unclear whether a generic "ChangeStatus" operation is needed, or just specific operations such as "Suspend()", "Resume()" and so on suffice. It should be observed that the last teleconference was EXPLICITLY devoted to start discussion of the implementation details, and in my previous mail I was saying that no progress has been made on deciding the implementation details (as discussion on that just started). Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
hi, Steven Newhouse wrote:
I’ve just had the chance to catch up with my email
i've just done the same ;)
and had not seen any comment to Andrew’s document?
I haven't seen any real comments to the GES rendering document either.
Was this discussed on the call this week?
Andrew's "extension" approach was the main topic of the last week call. On the other hand, the GES rendering draft was not yet addressed. bye, Balazs Konya
Hi team,
and had not seen any comment to Andrews document?
- I haven't seen any real comments to the GES rendering document either.
Yeah that was my idea with the factsheet, which had the views of both documents merged - but this was ignored and now we have again our two fronts... So, this document was not discussed - that's why I don't understand that it is not on the phone call agenda for #1 today and instead discussing the first front again - it would be fair to go to both documents, also having this document discussed. Moreno - what about putting this document on the agenda as well? Take care, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Balazs Konya -Sent: Wednesday, May 20, 2009 10:52 AM -To: Steven Newhouse; pgi-wg@ogf.org -Subject: Re: [Pgi-wg] Promised document - -hi, - -Steven Newhouse wrote: - > Ive just had the chance to catch up with my email - -i've just done the same ;) - -> and had not seen any comment to Andrews document? - -I haven't seen any real comments to the GES rendering document either. - -> Was this discussed on the call this week? - -Andrew's "extension" approach was the main topic of the last week call. -On the other hand, the GES rendering draft was not yet addressed. - -bye, -Balazs Konya -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
participants (8)
-
Aleksandr Konstantinov -
Andrew Grimshaw -
Balazs Konya -
David Wallom -
Etienne URBAH -
Moreno Marzolla -
Morris Riedel -
Steven Newhouse