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

3.5.1 "over the WAN was not robust and would fail after a period of time", why is that so? 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.

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

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.

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

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.

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

4.2.3 it is a very tight schedule in my opinion.

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

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.  
2 3.5.2 "OGF Usage Record standard", provide reference  
3 3.5.2 the abbreviation AMQ is not defined in terminology section. I would suggest to use ActiveMQ  
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.  
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).  
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?  
7 4.11.2 "the affected components were specified in 4.9.2" There are no components listed in 4.9.2  


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 *r*eferences, Information *s*ystem ..., GANTT *c*hart, etc. All sections of the same level should follow the same writing convention  
2 ToC sometimes a "-" is put before "Definition of subtask" sometimes not, e.g 4.16.4 vs 4.10.3  
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.  
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"  
5   Tables 1.5 and 1.6 are not "closed" on the left hand side.  
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),  

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

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatext internalReview r1 manage 5.0 K 2011-05-19 - 16:39 JedrzejRybicki Internal JRA1 review
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2011-05-19 - JedrzejRybicki
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback