EGI Verifier Guideline QC5
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 Reports
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.
Verifiers must fill all required fields for each product and write a Verification process summary into Executive Summary, this summary should include:
- A short summary of the installation and configuration process: Installation and configuration were successful?, If not explain any issue or bug found. If the product was rejected explain why.
- If its necessary Verifiers should include a comment for StageRollout: Configuration changes or minor issues found verifying the product.
- If a new QC is necessary and is not included, Verifiers must write a comment to SA2.2 to change current QC.
Acceptance or Rejection
QCs are Mandatory (M) or Optional (O).
- A product is REJECTED if it fails installation process.
- A product is REJECTED if it fails ANY Mandatory QC.
- A product is VERIFIED if it pass ALL assigned QCs.
- A product is VERIFIED if it fails ANY Optional QC.