EMI Review of the EGI QC Documents (Version 3) per Product


Each product team should review its document.

Deadline for the review

  • 15 March 2012
  • Write your feedback in the corresponding section below

Material to Review per Product

Each product team should review its document.

Done: Review of AMGA QC (EGI-AMGA-QC-V3-DRAFT2.pdf, 523.5 kB)

Review done by: Soonwook Hwang

This document is fine. But it is need to change some of the information for the handling of error messages.

9.1 There are two error messages in page 33 ~ 34

AMGA Soap Interface
Description [¡Error! No se encuentra el origen de la referencia.]
AMGA Streaming Interface
Description [¡Error! No se encuentra el origen de la referencia.]

  • I think you probably didn't find reference page although there is related information in [R 6]. So I propose to change to the detail reference informations for above two items.
  • Please modify "related Information"(page 33) to gLite AMGA [R 7] and modify "related Information"(page 34) to gLite AMGA [R 8]
10. Please modify AMGA WSDL Url to "http://amga.web.cern.ch/amga/soap_wsdair.html" in [R 7](page 40)*

Done: Review of Argus QC (EGI-ARGUS-QC-V3-DRAFT2.pdf, 522.2 kB)

Review done by: Valery Tschopp

  1. GENERIC_SERVICE_1: The last 2 tests expected outcome is should be inverted: Service is stopped -> Check service status -> Show a message stating the service is started. It should be if stopped, status is stopped.
  2. AUTHN_IFACE_2: The SAML Authentication requirement is not clear, and/or doesn't make sense in this context. The X.509 authentication make sense with HTTPS and client authentication, but I don't see how SAML authentication could work on HTTPS?!? The HTTPS protocol can not support client authentication based on SAML assertion, another protocol/layer is required.
  3. AUTHZ_ PEP_1: The SAML Authentication requirement is very doubtful as an input. User authentication with X.509 is easy to validate against the EGI IGTF trust anchors, but to validate a user authentication with SAML assertion is something completely different. It requires to establish a trust relation between the services, and this it actually not available in EMI or EGI...
  4. MON_PROBE_GENERIC_2: There is no description of the required functionality tests to be perfomed for the Argus probes. The operations community didn't give the Argus PT any descption of the tests they want to have (if any).

Done: Review of BDII QC (EGI-BDII-QC-V3-DRAFT2.pdf, 494.5 kB)

Review done by: Maria Alandes Pradillo

Document is fine. The part related to resource BDII should be also reviewed by all the other PTs which are affected by this.

Done: Review of CREAM CE QC (EGI-CREAM-QC-V3-DRAFT2.pdf, 702.5 kB)

Review done by: Massimo Sgaravatto

This talks about yaim, but it also says:
The configuration should not remove any previous manual configuration done
You can not expect it using yaim

  • AUTHZ_PCYDEF_3 (page 33)
I don't understand the "(Not Argus)" in the title

  • JOBEXEC_IFACE_1 (page 37)
I would say that DRMAA is something to interact with the batch system and not a "high level" interface

  • JOBEXEC_AVAIL_3 (page 46)
This is quite vague since no precise conditions (i.e. numbers) are given

Done: Review of FTS (EGI-FTS-QC-V3-DRAFT2.pdf, 534.9 kB)

Review done by: Oliver Keeble

The document is fine. One observation:

AUTHZ_* : FTS2 manages a list of DNs which are allowed to submit or manage the system. Banning involves removal from this list. Proper VOMS/FQAN support will come with FTS3.

The QC list will be integrated into the FTS3 roadmap.

Done: Review of LFC QC (EGI-LFC-QC-V3-DRAFT2.pdf, 568.4 kB)

Review done by: Oliver Keeble

The document is fine. A couple of comments:

METADATA_LFC_FUNC_2: this is implemented, but note that the acls are only on the meta data (see the catalogue synchronisation project in the data area for more info).

CLIENT_TOOLS_1: a reasonable request, but what should a product do in the contrary case? Changing an existing cli can cause more harm than good.

Done: Review of ARC Classic SE QC (EGI-SE-QC-V3-DRAFT2.pdf, 646.8 kB)

For ARC Classic SE see EGI-SE-QC-V3_ARC_Classic_SE.txt

Done: Review of DPM QC (EGI-SE-QC-V3-DRAFT2.pdf, 646.8 kB)

Review done by: Oliver Keeble

The document is fine. Some comments:

AUTHZ_ PEP_2 - DPM uses virtual ids and mapping to pool accounts is not necessary for all operations.

FTS requirements are not appropriate here.

STORAGE_DEVICE_2 - this is possible within certain constraints. Demonstrating compliance would need more detail on the expected use cases.

Missing: Review of Storm QC (EGI-SE-QC-V3-DRAFT2.pdf, 646.8 kB)

Review done by: Michele Dibenedetto

  • GENERIC_DOC_7: the pass/Fail criteria should be extended. If the information is not available (because the question is not applicable to the service) the field should be filled with NOT AVAILABLE or NOT APPLICABLE

  • GENERIC_DIST_1: is not clear what is requested with "Open source products must publicly offer their source code and the license with the binaries." That "with the binaries" should be clarified.

  • GENERIC_SERVICE_1: the last two Test Description are wrong, the correct status should be checked

  • GENERIC_SERVICE_4: there is missing a prerequisite: somewhere should be stated which is the "normal capacity" of a certain service

Done: Review of dCache QC (EGI-SE-QC-V3-DRAFT2.pdf, 646.8 kB)

Review done by: Christian Bernardt


Done: Review of Unicore Products QC (EGI-Unicore-QC-V3-DRAFT2.pdf, 671.7 kB)

Review done by: Krzysztof Benedyczak

Important remark: The review is not complete. What is here now is written from the UNICORE Security PT perspective, other PTs may have other comments.

  1. 8.1. (applicable to all UNICORE services) proxy certificate authN is not supported and won't be until the EMI caNl is integrated with all UNICORE components. Official deadline for this is EMI 3.
  2. 9.1.1. It is not possible to write rules using gLite FQAN. It is not planned to add such support. It would be advised to change this requirement, so it would say that banning users with specific roles and group membership must be possible.
  3. 9.1.2. As above plus it should be reworded
  4. 9.1.ALL - The two requirements for authN are on a different level. The first one says what credential should be used for authentication (X.509 cert), the other what protocol (SAML Authn). This makes no sense, also in the derived requirements. Either the first should be changed to sth. like "TLS/SSLv3 with client-side authentication must be supported for authN" or the latter to state what identity types in the SAML assertion should be supported. I guess that the EGI's intention was to have rules specifying mandatory and desired protocols and mandatory and desired identity representation formats (e.g. is email address desired as identity format? or SAML opaque string? or maybe only X.509 certificate in SAML authN assertion?). What is more in case of SAML authN it should be stated what bindings are desired - saying that support for "SAML authentication is desired" means nothing or everything.
  5. 9.2. AUTHZ_PEP_1 This is so obvious that I think it doesn't make sense to put it. But if this is here, then "SAML Assertion" is quite doubtful as an input (see the above comment).
  6. 9.3. AUTHZ_PEP_2 Support for pool accounts is not available in UNICORE. We plan to add this but this is not in the workplan (which is under preparation). Plus FQAN comment as above.
  7. 11.1. (VERIFY THIS) I don't think it is or will be available in UNICORE.

From the point of view of the Clients PT, it's ok regarding clients. Some general comments:


Swap the expected outcomes.

Pre-condition Service is stopped
Test Check service status
Expected Outcome Show a message stating the service is started.

Pre-condition Service is started
Test Check service status
Expected Outcome Show a message stating the service is stopped.


Think of merging PARALLEL_MPI_1 & PARALLEL_MPI_2 as well as PARALLEL_OMP_1 & PARALLEL_OMP_2

In UNICORE, compilation and subsequent execution would be crafted as a workflow.

-- BjoernHagemeier - 07-Mar-2012


Make this req. optional. We are highly doubtful of its utility and cannot guarantee that it will be implemented in UNICORE.

"Information published by the appliance must be available through LDAPv3 protocol" Manadatory NO

Done: Review of VOMS QC (EGI-VOMS-QC-V3-DRAFT2.pdf, 560.5 kB)

Review done by: Andrea Ceccanti

The document looks good.

-- BjoernHagemeier - 11-Jun-2012

Missing: Review of WMS and LB QC (EGI-WMS_LB-QC-V3-DRAFT2.pdf, 712.2 kB)

Review done by: Write here the Reviewer's name

Write your review here of each QC in the document for which you have comments If you reviewed the document and all is fine for you please write so in here

Done: Review of gLite MPI QC (EGI-gliteMPI-QC-V3-DRAFT2.pdf, 418.3 kB)

Review done by: E. Fernandez

Document is fine.

Files in ZIP file:

  • AMGA QC (EGI-AMGA-QC-V3-DRAFT2.pdf, 523.5 kB)
  • Argus QC (EGI-ARGUS-QC-V3-DRAFT2.pdf, 522.2 kB)
  • BDII QC (EGI-BDII-QC-V3-DRAFT2.pdf, 494.5 kB)
  • CREAM CE QC (EGI-CREAM-QC-V3-DRAFT2.pdf, 702.5 kB)
  • FTS (EGI-FTS-QC-V3-DRAFT2.pdf, 534.9 kB)
  • GSISSH (EGI-GSISSH-QC-V3-DRAFT2.pdf, 481.9 kB)
  • Gram 5 QC (EGI-GRAM5-QC-V3-DRAFT2.pdf, 611.3 kB)
  • GridFTP (EGI-GridFTP-QC-V3-DRAFT2.pdf, 476.8 kB)
  • GridSAM QC (EGI-GridSAM-QC-V3-DRAFT2.pdf, 591.6 kB)
  • GridWay QC (EGI-GridWay-QC-V3-DRAFT2.pdf, 534.7 kB)
  • LFC QC (EGI-LFC-QC-V3-DRAFT2.pdf, 568.4 kB)
  • MyProxy QC (EGI-MyProxy-QC-V3-DRAFT2.pdf, 492.3 kB)
  • SAM/MyEGI (EGI-SAM-QC-V3-DRAFT2.pdf, 562.4 kB)
  • SE (DPM, Storm, dCache, ARC Classic SE) QC (EGI-SE-QC-V3-DRAFT2.pdf, 646.8 kB)
  • Unicore Products QC (EGI-Unicore-QC-V3-DRAFT2.pdf, 671.7 kB)
  • VOMS QC (EGI-VOMS-QC-V3-DRAFT2.pdf, 560.5 kB)
  • WMS and LB QC (EGI-WMS_LB-QC-V3-DRAFT2.pdf, 712.2 kB)
  • gLite MPI QC (EGI-gliteMPI-QC-V3-DRAFT2.pdf, 418.3 kB)
Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip EGI-QC-per-Product-V3.zip r1 manage 9542.4 K 2012-02-28 - 09:08 AlbertoAimar  
Texttxt EGI-SE-QC-V3_ARC_Classic_SE.txt r1 manage 3.2 K 2012-03-07 - 13:02 UnknownUser Comments for ARC Classic SE
Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r22 - 2012-10-22 - 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