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.

Difference between revisions of "2019-bidding/umd-cmd-quality-assurance"

From EGIWiki
Jump to navigation Jump to search
(Replaced content with "{{Template:Deprecated}}")
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Template:Op menubar}}{{Core_services_menubar}} {{TOC_right}}
{{Template:Deprecated}}
'''Go back to the [[EGI_Core_Activities_Bidding#PHASE_II_May_2016-December_2017|EGI Core Activities Bidding page]].'''
 
= Service name: UMD and CMD quality assurance =
This service aims at vrifying UMD and CMD products against a list of quality criteria and providing additional verification through a Staged-Rollout procedure of the software before the release in production.
 
== Introduction ==
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.
 
== Coordination==
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.
 
== Operations ==
This task will operate two cloud infrastructures based on OpenNebula and OpenStack  to  be  used  as  a  testbed  for  the  verification  of  the  software products.  The  size  of  the  infrastructure,  each  VM  with  a  maximumof  12 VCPU40  GB  memory  and  400  GB  disk,  should  allow  the  deployment  of several VM / Containers 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  the  UMD release  notes  and  known  issues  wiki  pages.  The  task  leader  must participate to 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;
*create the corresponding xml file for each Product per Platform and Architecture (PPA)
*monitor and handle the software provisioning process
 
== Maintenance ==
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.
 
== Support ==
Support is provided via EGI Service Desk Support Units: EGI UMD Quality Assurance, UMD Product Submission
 
== 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.
 
== Quality of Support level ==
* Medium
 
== Effort (EGI-related activities) ==
Bids  planning a total effort of about 19 Person Months/year (STC) would allow these services and activities to be addressed appropriately. Effort may be provided as part of either the INFRAEOSC-07 and INFRAEOSC-03 projects.
 
== Effort (EOSC-related activities) ==
Partners are encouraged to submit details of activities and proposed costing of effort for EOSC Hub related activities. This may include activities related to development of new functionality required by EOSC communities in addition to activities delivering services to these communities.

Latest revision as of 17:02, 20 November 2019

Alert.png This article is Deprecated and should no longer be used, but is still available for reasons of reference.