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 @

2016-bidding/UMD CMD quality assurance

From EGIWiki
(Redirected from 2016-bidding/umd quality)
Jump to navigation Jump to search
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

EGI Core services menu: Services PHASE I Services PHASE II Services PHASE III Bids Payments Travel procedure Performance

Go back to the EGI Core Activities Bidding page.

  • Service name: UMD and CMD quality assurance


The quality criteria are the functional and nonfunctional requirements that a product must fulfill to be released in UMD and CMD; these include generic requirements applicable to every product, and specific requirements applicable to the capabilities supported by a component.

The Staged Rollout is a procedure by which certified updates of the supported middleware are first tested by Early Adopter (EA) sites before being made available to all sites through the production repositories. This procedure permits to test an update in a production environment that exposes the product to more heterogeneous use cases than the certification and verification phase. This allows the discovery of potential issues and the addition of corresponding mitigation information to the UMD and CMD release notes.

The Quality Criteria and the Staged Rollout are applied to UMD and CMD and all the distributions that are managed within the UMD and CMD software provisioning infrastructure, with particular reference to the CMD (Cloud Middleware Distribution) releases.

Technical description

All the products released in UMD and CMD must be verified against the relevant acceptance criteria. Products must be deployed in a controlled environment. Every product in every distribution must have a verification report associated, with the results of the verification process. The verifiers must be familiar with the core products used in EGI, the most common site configurations and third parties components such as DBMS and LRMS. The software to be verified involves user facing services, HTC services, storage services, cloud services, and all the products that are critical for EGI communities and are part of the supported distributions.

This task will also test the release candidates to check the dependencies and installability of the packages before the official release.

The distributions maintained per year are expected to be about 4-5. The software releases per distribution are expected to be 6-10 minor releases per year, and supporting 3-4 operating system platforms.

Staged Rollout is performed by Early Adopter (EA) sites who volunteer to deploy products fulfilling the acceptance criteria in the production infrastructure, exposing them to real users and real use cases.


The task must coordinate the verifications when the process is outsourced to developers or user communities, this means: overview to advancements in the process and collect the reports produced during verification, making sure that the relevant information (GGUS tickets opened, known issues) are properly propagated to the software releases.

During staged rollout this task is responsible for the coordination of the Early Adopters activity, namely assign and monitor the progress of each individual product and corresponding EA teams, collect and analyze the reports provided by the EA team and in case of issues found make sure that relevant information is properly handled.


This task will operate a cloud infrastructure to be used as a testbed for the verification of the software products to be included in the release. The size of the infrastructure should allow the deployment of several VM in parallel to test also for service interoperability. Verification of products should be outsourced only when the effort required would be too high (for example for lack of expertise), or for technical limitations that prevent to deploy the service in the testbed.

Release candidates must be tested for the installation of all the components, new and already available in the repositories. The test, possibly automated, must be able to generate a report in few hours (less than one working day, possibly 2-4 hours).

This task is also responsible for producing and maintaining corresponding release notes and known issues wiki pages. The task leader must participate the periodic EGI Operations meetings and report about the status of the UMD and CMD releases. Together with those activities it also includes:

  • maintenance of the EA tables;
  • contribute in handling the PPAs advancement in the software provisioning process.


The task should also review the set of quality criteria and add/remove criteria based on the requirements of the final users and service providers. This activity is on-request.


The activity must provide support through the EGI Software provisioning GGUS support unit, during working hours.

Service level targets

The estimated number of products to verify in one year is 200 PPA.

Within this envelope, PPA should be verified within 1 month from the submission of the PPA by the developers.


Bids planning a total effort between 20 and 24 Person Months/year would allow these services and activities to be addressed appropriately.