Difference between revisions of "EGI Core activities:2015-bidding UMD quality"
|Line 47:||Line 47:|
= Effort =
= Effort =
Bids a between 12 and 18 Person Months/year would allow these services and activities to be addressed appropriately.
Revision as of 16:45, 2 July 2015
|Main||EGI.eu 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 quality assurance
The quality criteria are the functional and nonfunctional requirements that a product must fulfill to be released in UMD; 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 release notes.
All the products released in UMD must be verified against the relevant acceptance criteria. Products must be deployed in a controlled environment. Every product in UMD 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 UMD.
This task will also test the release candidates to check the dependencies and installability of the packages before the official release.
UMD releases are expected to be 6-10 minor releases per year, distributed in two major releases, and supporting three 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 UMD release.
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 UMD products. 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.
UMD 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 the UMD 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 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 UMD Software provisioning GGUS support unit, during working hours.
Service level targets
The estimated number of products to verify in one year is 200 PPA.
Bids planning a total effort between 12 and 18 Person Months/year would allow these services and activities to be addressed appropriately.