DNA1.3.1 Review (Francesco)

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: DNA1.3.1
Title: DNA1.3.1 - Technical Development Plan Doc. identifier: EMI_DNA1.3.1_draft.docx
Author(s): Balazs Konya Due date: June 2010

Identification of the reviewer
Name: Francesco Giacomini Affiliation: INFN EMI Activity/External project or Institute: SA1

Review date 2010-11-04
Author(s) revision date 19/11/2010
Reviewer acceptance date ??/??/2010

Reviewed document (minor corrections)

BK: I accepted all the minor corrections in the revised version

General comments

The document is acceptable. The other comments (general and specific) are just suggestions for improvement and clarification.

The deliverable template is not fully followed, e.g. the references should be moved from the end of the document to within the introduction; the section "Application Area" is missing.

BK: The references are deliberately moved to the end of the document. I very much dislike the template in this respect. I remember this template change was proposed in the PEB, it just did not get realized in the template. I don't know what is the "Application area" section is. That i don't see in the template. Another deliberate deviation from the template was to move the Executive Summary out of the "Introduction" and put it as the first section of the document (another template change i proposed to the PEB).

References are not real references.

BK: I tried to find out how references should be handled in the doc. I chose to follow DNA1.1 and DSA2.1.

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

Detailed comments on the content

N Page Section Observations Is Addressed?
1 1 Abstract It's not the same text of the DoW.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: The PEB decided that the overall technical plan (this deliverable) should not contain details such as the product team development plans. That is why the second sentences got removed compared to the DoW abstract: "It contains ... plan with deliverables and milestones for each Product Team.."
2 7 2.2 and Glossary There is no EMI glossary at http://www.eu-emi.eu/about/glossary/.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: I had proposed the creation of such a glossary long time ago. It shouldn't take more than one day for NA2 to put up a glossary.
3 8 3 What about summarizing the requirements here? just to give an idea of what we got at the beginning.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: Done. Collected the most important requirements from the UMD document (see enumeration on Page 8).
4 8 3 Elaborate a little bit on what "well-established collaboration channels" are or will be soon in place.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: In a previous version the above sentence was followed by a reference pointing to the "Collaboration" deliverable. I was asked to remove that reference due to immature state of the deliverable. I am not in the position to describe those collaboration channels and i don't think it belongs to this document.
5 12/13 4 Some components (50 to 53) of the gLite Information System have evolution set to no, but I guess they would need to be ported to GLUE2.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: Developments related to implementation of an EMI agreement (e.g. GLUE2) fall into the category of Harmonization - integrate. Evolution is a type of development that does not address "harmonization", it is a kind of "stand alone new feature" development. This is why the glite infosys components have "harmonization" and no "evolution".
6 13 4 Why are Trustmanager and Util-java investigated for phase-out? to be replaced by the common authN library?
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: yes. that was the idea. In the table we deliberately put "investigate for phase out" for every component that might have a little chance of being removed or replaced.
7 13 4 Why do we still need to investigate if LCAS and LCMAPS are to be phased-out? consequently also LCMAPS-plugins-c-pep should be phased-out at some point.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: LCAS/LCMAPS phase out was discussed lengthy with John and Nikhef team. It was not possible to be more definite than just "investigate". Concerning the LCMAPS-plugins, i changed that to "investigate" too.
8 13 4 Delegation Java has evolution set to no. But I guess it would be affected by the shift to SAML.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: The SAML work is again "harmonization - integrate" and not evolution.
9 14 4 Why is Argus EES mentioned explicitly and not the other Argus components? because its status is different?
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: Yes, and also because this component is proposed as a key player in EMI virtualization. The Argus team has plans to offer this component, independently from the other Argus modules, as a virtualization manager or something similar.
10 16 5.1 I guess figure X means 1.
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: Fixed.
11 16 5.1 Second bullet: which "remaining two areas"?
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: Made it more precise by naming the security and infosys areas
12 18 5.2 In the table, what is the meaning of the Due date? end of development, release, other? I remind that, for example, if EMI-1 is due at M12 it means that the software needs to be ready at M10 (which is also a milestone for JRA1).
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: This is a high level plan where the due dates of the objectives are just indications to show if a certain development task is scheduled to be completed for the first, second or third year. That is the intended granularity with some exceptions where mid-year due date is given. Yes, the area leaders and PT leaders are very well informed about the code freeze date vs. release date. The development plans are the proper documents to judge whether a certain feature will be ready for EMI-1,2,3 or not.
13 19 Technical Objectives of Data area Objective 3: does it refer to data transfers, i.e. as an alternative to GridFTP?
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: yes, the "SE offering https" objective is exactly about that.
14 19 Technical Objectives of Data area Objective 4: protocol "file" only for local access or also remote?
-- FrancescoGiacomini - 04-Nov-2010
BK 18/11/2010: It is only local. Within data objective 4, the "file" access, is a "code name" for POSIX access to be provided via mounted file systems. It'll be possible to mount an SE. This objective is about support for NFS4.1

-- BalazsKonya - 28-Oct-2010

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r6 - 2010-11-19 - BalazsKonya
    • 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