JRA1/SA1 Deliverable Review Form

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

Identification of the reviewer
Name: K. Bendyczak Affiliation: UWAR EMI Activity/External project or Institute: SA1/JRA1

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

Review (comments in text, changes): EMI-DJRA1.1.2-Compute_Area_Work_Plan-v0.5-review.odt

General comments

Here I included the most important remarks. These issues are likely to require some more effort then performing editing correction only. The sorting is starting (very roughly) from the most important issues. More details in comments (it is good to read them having the original deliverable text).

  1. Clients (4.4, 4.9) The whole plan for compute clients looks questionable.
    1. The precise definition of the approach which is going to be adopted must be done first. This is delayed from the Y1. This point is probably hidden in 4.9, but should be highlighted and get a subtask with a short timeline.
    2. All the subactions in 4.4 depends on the above decision. Assuming the current suggestion (a separate client) none of them should even be started. According to the current timeline they can be finished by the time this task is resolved (what can possibly mean a wasted effort). There are also other remarks in the text to the definition of concrete subtasks.
  2. Monitoring (4.24) This is a very vaguely defined and a risky goal. This whole remark is probably also related to the overall technical plan.
    1. "e.g. Nagios": are PTs free to choose? Or do they have to support all existing frameworks in the market? Or only Nagios?
      • Monitoring platform must be defined.
      • Serious risk is that a middleware provider won't use the platform chosen in the point above. What then?
    2. Nagios API is extremely trivial (really). But implementing monitoring system, consisted of probes is not. It must be defined what such probes do? Are active or passive? What are configuration requirements (e.g. in this compute case reservation/priorities in LRMS)? And in the first place: dependencies between probes. I enumerate this to stress that this task can not be done by independent PTs. It can be only achieved in a centrally coordinated manner by defining a whole middleware monitoring framework.
    3. The task should be related to the fact that there are existing probes (Nagios/SAM supporting gLite, UNICORE monitoring being integrated with SAM in EGI, I don't know about ARC and dCache). The code is going to be taken over? Are the original owners acknowledged, did they agree? Or is it a development from scratch (if so then why?).
  3. Accounting 4.6, 4.7 The description mentions three objectives: UR + aggregated UR and service interface+protocol. The subtask "define EMI UR" rather doesn't refer to the latter action. Also it is not explained at all here. Due date is absolutely unrealistic. Basic EMI UR is possible by this time, but a work on an aggregated usage record has not even been started and the same holds about the mentioned above "service interface and data transport protocol". Suggestion: define two new subactions for those remaining tasks, and prolong the whole A6. Also consider that none of UNICORE accounting extensions is included in EMI. What about this?
  4. Overlaps and inconsistency with Sec. Area plan w.r.t.
    1. SAML attributes. Generally presence of action C3.1; dependency of C4.1 on C3.1.
    2. EXECUTIVE SUMMARY and 3.8: Argus (EES here) won't fully replace glexec. Also I'm not sure if this deliverable should mention the possible removal of LCMAPS and LCAS as this is sec. area domain and is somehow questionable as we can read there.
    3. Finish dates of C1.1, C1.2; why same actions are in two workplans (security and compute)?
  5. 3.6, 3.7 and 3.8 and 4.14 One very important point is missed. The ATHPRF and everything related is probably stated correctly. But there is a new EMI CE profile, which is not specific to CREAM, and is a way to go. What about it? I know that there is point 4.14 but without discussing the above work the situation is unclear.
  6. 3.1. I miss information on succeeding/turning down of the two problems signaled in the DJRA1.1.1: (1) lack of standard security profile in relation to OGSA-BES and (2) missing attributes in job description (e.g. for data requirements, to support epilogue/prologue, to support resubmission, to manage run time environments, etc.).
  7. 3.17, 3.18 - not done in time, disappeared silently from the Y2.
  8. The same remark as above holds for some other actions (like one subpart of GSI removal).

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

Only one minor comment: after reading the document I have a feeling that some of the sections are very detailed (e.g. 3.19) and some contain only some very general statements (3.11 or even 3.9 where there is a lot of text but only few pieces of a concrete information). It would be good to keep the reports and descriptions on the same detail level.

Detailed comments on the content

KB: As the number of remarks is approaching 100 (for sure it is well over 50) I only put them in the document (of course with changes tracking turned on). The most important notes are pasted also in General section above.

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?

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

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2011-05-20 - unknown
    • 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback