EMI Web>EmiDocuments>EmiDeliverables>DeliverableDJRA142>DJRA142ReviewJRA1SA1JR (2011-05-24, LaurenceField)

JRA1/SA1 Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI	Deliverable or milestone identifier: D5.4.2
Title: DJRA1.4.2 - Infrastructure Area Work Plan and Status Report	Doc. identifier: EMI-DXXX-CDSREF-Title-vx.x
Author(s): L. Field	Due date: __

Identification of the reviewer
Name: Jedrzej Rybicki	Affiliation: JUELICH	EMI Activity/External project or Institute: JRA1/SA1

Review date	mm/dd/yyyy
Author(s) revision date	mm/dd/yyyy
Reviewer acceptance date	mm/dd/yyyy

Attach the reviewed document to the deliverable page, put here a link

General comments/remarks:

We already have a "deeper" internal JRA1 review where Laurence addressed most of my comments.

Section 3.2 A short motivation for the adoption should be provided. It is a general remark: the technical description of the objectives should include at least one motivation sentence and expected outcome (optimally from user perspective).

LF: Added a motivation sentence, Grid interoperability.

3.5.1 "over the WAN was not robust and would fail after a period of time", why is that so?

LF: Added a sentence to say that we need to investigate the reason for this failure.

3.7 "Through this research, the task force chose the existing capabilities of Infrastructure as a Service (IaaS) Cloud model as a reference architecture.", why? It is a general remark: I would expect that the document is either self-contained and complete by either answering such questions or by providing references to documents where the information can be found.

LF: The document is referenced in a previous sentence. I have changed the sentence to explain that a reference archiecture is described in the document.

4.2.2 vs 4.3.2 both tasks are investigations and for one the affected components are listed for the other no. General remark: I don't buy this excuse of not listening components for investigative tasks.

LF: For some objectives which require us to invesitagate which components requrie changing, we can't identify accuratly before we have done the investiagation. In which case what is written is honest and accurate.

Sure we should agree on what "affected/involved" means, but as soon as a component undergoes some examination it is involved IMHO. My general impression is that the lists of affected components are not prepared with the due precision and care. Some examples follow, I would suggest that the whole report should be revised in this regard.

LF: These lists were carfully prepared and aggree with the component list in DNA1.3.2.

4.11 It seams to be one of the most important goals in Infrastructure Area (from EMI perspective). I would expect a more exact description of what is expect to be achieved there.

LF: I agree that it is an important objective. However, the most important aspect is the plan, not the implementation of that plan (4.9).

I cannot find a place where the following technical objective (DJRA1.3.2) is addressed: I11 "Devise a plan for substantial simplification and reduction in the number of infrastructure area CLIs, libraries, internal components and services."

LF: This is addressed by objective 4.9.

Additional recommendations (not affecting the document content, e.g. recommendation for future work)

The technical objective: X17 "Introduce minimal DOS protection for EMI services via configurable resource limits." seems to affect the infrastructure area. It is not included in the workplan.

LF: I did not include it as I disagree with such general objectives, like the software must be secure. These are properties not objectives! How do you know that you have achived your objective?

4.15.4 I wonder why SA/JRA1.7.2 teams are not involved here? Is there a cooperation envisioned?

LF: Are are are not? Area leaders define the objectives but JRA1 is responsible for overseeing the implementation of these workplans.

4.2.3 it is a very tight schedule in my opinion.

LF: I agree but that is the deadline in DNA1.3.2. I think that most of the acctual work has been done, including implementation, so only a report is required.

4.8, 4.9 "this technical objectives is to provide"? not sure myself.

LF: Double-checked with an English expert and this is fine.

Detailed comments on the content

Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Alternatively all changes must be listed in the document itself using Word change tracking features (if you use Word)
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described

N°	Page/Section	Observations and Replies	Is Addressed?
1	Section 3	"As a result the PTB decided to move the Logging and Bookkeeping component from the Infrastructure Area to the Compute Area to help focus effort.", the information when it happened should be provided. LF: Addded the date when this meeting took place.	yes
2	3.5.2	"OGF Usage Record standard", provide reference LF: Added a reference.	yes
3	3.5.2	the abbreviation AMQ is not defined in terminology section. I would suggest to use ActiveMQ LF: Done	yes
4	4.4.2	affected components include EMI Registry, and SAGA. But, if I understand it correctly, the information for the registry need to be somehow provided, so I guess much more components are involved here. For some of them you might even expect that modification will be needed. There is also UNICORE Registry, would it be affected? probably. LF: A new client will be required for the EMI service Registry so this will not affact any existing publishers. This objective does not require and changes to the UNICORE Registry. How the EMI Registry will affect the Unicore Registry interms of a possible replacement is addressed by the harmonization objective.	no
5	4.7.3	The subtask definition sounds very similar to the goals already achieved in the first phase of the project (compare 3.7), it is not clear what kind of new findings should be included in the report which is due to M24. Furthermore the objective specify that a list of architectural changes should be provided, this is not reflected in the schedule. We don't want to miss such an important list, do we? Apart from the fact that a strategy provided in M24 will probably not be implemented in EMI (as there will be not enough time). LF: So there may be a difference here between the work be have already done and the official dealines in the DoW. Anyway, this is an issue that I would like to raise at the project management level. Lets leave this issue open for futher dicussion
6	4.8.3	"Obtain Compute Usage Record specification", 3.5.2 says that in the first phase, some development based on this standard was already conducted. How if the standard is yet to be obtained in M13? Or it is a different standard? What does it mean "to obtain" here? Do we have to buy it? LF: This is a tricky issue. The OGF Isage Record exists but it may not be good for us and we have to extend it. This work was an objective in the first year for the compute area. I use the word obtain as we are not defining it but have to get it from somewhere, the compute area.	no
7	4.11.2	"the affected components were specified in 4.9.2" There are no components listed in 4.9.2 LF: changed to "will be identified in"	yes

Presentation:

Use official EMI layout (with EMI logo, header, page numbers etc), how could I miss in JRA1 internal... my bad!

N°	Page/Section	Observations and Replies	Is Addressed?
1	ToC	consistent usage of capital letters in ToC e.g references, Information system ..., GANTT chart, etc. All sections of the same level should follow the same writing convention	yes
2	ToC	sometimes a "-" is put before "Definition of subtask" sometimes not, e.g 4.16.4 vs 4.10.3	yes
3	ToC	sometimes the section "extended technical description of the objective" is omitted and the description (usually not very "extended") follows the section title. I might be a good idea to follow this principle (or the other one) consequently through the report.	yes
4	References	consistent usage of protocol in address, is: "R5 http://cdsweb.cern.ch/record/1277582 R6 www.ogf.org/documents/GFD.147.pdf" should be: "R5 http://cdsweb.cern.ch/record/1277582 R6 http://www.ogf.org/documents/GFD.147.pdf"	yes
5		Tables 1.5 and 1.6 are not "closed" on the left hand side.	yes
6		Text formatting in 3.4 (is left), 3.7 (funny spaces at the end of lines and sentence broken in the middle), some tables have text floating left (e.g. 4.3.3) some have justified (e.g. 4.2.3),	yes

Any other modification, spelling or grammatical corrections, etc must be done directly in the document using tracked changes or similar mechanisms that allows the authors to identify which correction is suggested.

-- FloridaEstrella - 06-May-2011

-- JedrzejRybicki - 19-May-2011