Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

EGI Verifier Guideline QC5

From EGIWiki
Revision as of 09:37, 20 April 2011 by Asimon (talk | contribs)
Jump to navigation Jump to search
Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary


Quality Assurance | Quality Criteria Definition | Quality Criteria Dissemination | Quality Criteria Verification | Verifier Guideline | Verification Testbed | Glossary





Objective

The main objective of this guideline is to aid new SA2 verifiers to complete Verification process successfully. This guideline includes these topics:

  • How to request and manage a new SA2 testbed machine.
  • How to handle product RT information and install new middleware.
  • How to use QC verification reports:
    • Which QC tests must be checked.
    • How to fill QC reports and Executive Summaries.
  • When and how a product is rejected or accepted.
    • Differences between critical and non critical bugs.
    • Mandatory and Optional QCs.


SA2 Verification Testbed

Each released product MUST be installed in different machines. SA2 Verifiers should request a new virtual machine for verification test submitting an email to grid-admin(at)cesga.es. This email should include:

  • Subject: SA2 Verification Tesbed request.
  • Body:
    • Verifier Name.
    • Product name to verify.
    • OS and hardware requirements (if necessary)
    • Verifier SSH public key (generated id_dsa.pub)

Verification team will submit a confirmation email to connect to the new machine (public IP, hostname, etc).


Middleware Installation

Verifiers should be able to connect new created VM machines to start verification process, these machines include:

  • NTP configuration.
  • EPEL and EGI-trustanchors repositories.
  • Host certificate (hostcert.pem and hostkey.pem)


Verifier must install a new repo for each product, this information is available at RT ticket field:

  • Custom Fields->RepositoryURL

Create a new repo file into /etc/yum.repos.d, as example:

  • cd /etc/yum.repos.d
  • vi test_sa2.repo

[arc-ce]

name=arc-ce

baseurl=http://admin-repo.egi.eu/sw/unverified/emitest.arc-ce.sl5.x86_64/1/0/0/

enabled=1

#To use priorities you must have yum-priorities installed

priority=30

  • yum update

Now verifier must install the product metapackage which is included into RT release.xml file (Custom Fields->ReleaseMetadata). An example: rt.egi.eu/rt/Download/CustomFieldValue/8712/release-voms-ppa.xml. In this example emi-voms-mysql is the package required for VOMS-Mysql product installation.

  • yum install emi-voms-mysql

Verifier must check missing dependencies or packages. If any issue is found installing the new middleware the Verifier must open a GGUS ticket directly to product Technology Provider.

QC Verification Report

RT workflow and Verification Templates links are available in: Quality Criteria Verification
. First of all verifiers must check QC service mapping to know which test must be verified for each product. This service mapping is available here QC Verification service mapping and Verification/Executive Summary templates are available here: QC Verification Templates.

QC