Difference between revisions of "EGI Software Component Delivery"

From EGIWiki
Jump to: navigation, search
 
(71 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<br> <br> DRAFT<br>
+
{{Tech menubar}}
 +
{{TOC_right}}
  
= EGI Software Component Delivery  =
+
<br> EGI's UMD Provisioning activity governs and executes two main processes:
  
== <span style="background: #ffff00">Component r<span style="display: none;" id="1423728260410S">&nbsp;</span>oadmap and release plan</span>  ==
+
#'''[[Software Provisioning Process|Software Provisioning Process]]:''' That handles software delivery from software development teams, aka Technology Providers (TP), Quality Assurance and Reporting.&nbsp;  
 +
#'''[[UMD Release Process|UMD Release Process]]: '''That collects tested Products per Platform and Architecture (PPAs) into UMD Releases
  
<span style="background: #ffff00">The Provider will publish a roadmap
+
<br>  
for each component it wishes to release to EGI. The roadmap may be
 
consolidated into one document with the roadmaps for other components
 
if the Provider releases more than one component to EGI. The roadmap
 
must contain:</span>
 
 
 
*<span style="background: #ffff00">All planned major component
 
</span>releases
 
 
 
*<span style="background: #ffff00">All planned minor component
 
</span>releases
 
 
 
*<span style="background: #ffff00">Planned new features in the
 
</span>component
 
 
 
*<span style="background: #ffff00">Incompatibilities between releases
 
</span>
 
  
 +
Of Technology Provider interest is the Software Provisioning Process, with its 3 steps:
  
 +
#'''Software Delivery''' – Technology Providers submit new software releases<br>
 +
#'''Software Assessment''' – through Quality Assurance &amp; Staged Rollout
 +
#'''Reporting '''– inform TP about outcome of the software provisioning process
  
 
<br>  
 
<br>  
  
<span style="background: #ffff00">The Provider will update the
+
Small workflow diagram representing status of products through the Software Provisioning Process:  
roadmap(s) every half year (six calendar months) at least one
 
calendar month before EGI publishes the UMD Roadmap on its scheduled
 
dates [Błąd: Nie znaleziono źródła odwołania]. </span>
 
 
 
<br>
 
 
 
<span style="background: #ffff00">The Provider will make available a
 
release plan for each component published in the Provider’s
 
software repository. The Provider may consolidate release plans of
 
more than one component into a consolidated series of one or more
 
documents, for a better overview. The release plan must provide the
 
planned release dates for all maintained software components for at
 
least one year into the future and must include the release dates for
 
</span>
 
 
 
*<span style="background: #ffff00">All major releases</span>
 
 
 
*<span style="background: #ffff00">All minor releases</span>
 
 
 
<br>
 
  
<span style="background: #ffff00">The Technology Provider agrees to
+
[[Image:Software Provisioning Process.png|300px|Software Provisioning Process.png]]
inform EGI whenever the release plan is changed.</span>
 
  
 
<br>  
 
<br>  
 
=== R<span style="background: #ffff00">elease delivery and format</span>  ===
 
 
<span style="background: #ffff00">The Provider agrees to deliver
 
releases on a regular basis and provides electronic access to the
 
release contents as described in [Błąd: Nie znaleziono źródła odwołania].
 
The new release must be delivered by creating a tracker artefact in
 
GGUS containing XML based technical description of the release [Błąd: Nie znaleziono źródła odwołania].
 
</span>
 
  
 
<br>  
 
<br>  
  
== Quality Assurance  ==
+
= Initial activities - Joining UMD Release Team<br> =
 
 
<span style="background: #ffff00">The Provider understands and
 
accepts the Software Provisioning Process as described in EGI-InSPIRE
 
Milestone MS503 [Błąd: Nie znaleziono źródła odwołania] and its
 
designated successors.</span>  
 
  
<br>  
+
To be included in [https://wiki.egi.eu/wiki/URT UMD Release Team (URT)] the interested Technology Provider should provide following information:<br>  
  
=== <span style="background: #ffff00">Acceptance Criteria</span>  ===
+
#'''Name '''of the Product team
 +
#'''Contacts '''(support email address, web site address)
 +
#Name and contact details of the Component Development '''Team Leader'''
 +
#'''Description''' of the Component/Product and its Purpose<br>
 +
#'''Release channels''' for the product:  
 +
#*where to find the packages and their updates
 +
#*components/products should be provided in the native packaging format of the OSs supported in UMD (i.e. as rpms for SL5 &amp; SL6, and deb packages for Debian)
 +
#*packages should have dependencies on packages provided by the respective OS and EPEL (for Fedora/SL family)
 +
#*any other external dependencies should be also provided or referenced as being provided by other Technology Providers part of the URT team
 +
#'''Documentation '''references – installation &amp; configuration guides, release notes, known issues and troubleshooting, reference cards
 +
#Which releases, '''versions''', are going to be released in UMD and with which support calendar
 +
#Communicate if TP have information on sites already deploying the software that can be interested in acting as '''Early Adopters''' in the staged rollout phase.
  
<span style="background: #ffff00">The evolution of acceptance
+
All information will be included into [[UMD_products_ID_cards|UMD products ID card]]
criteria is a normal process considering the settings within which
 
EGI and the Provider operate. </span>
 
  
 
<br>  
 
<br>  
  
<span style="background: #ffff00">Through active participation in the
+
To send join request please read: [[UMD Release Team#How_to_join_URT|'''How to join''']]
TCB the Provider advises EGI on the effort required to implement any
 
changes to generic or specific acceptance criteria that may affect
 
any of the maintained software components that are part of, or
 
considered to be part of, the UMD. </span>
 
  
 
<br>  
 
<br>  
  
=== T<span style="background: #ffff00">est plans</span>  ===
+
With the help of the EGI UMD Release Team (URT), the following steps need to be performed:  
 
 
<span style="background: #ffff00">The Provider agrees to formally
 
provide or make available to EGI the complete test plans and results
 
of continuous testing and integration of each maintained software
 
component. </span>
 
 
 
<span style="background: #ffff00">The test plan for a given release
 
of one particular component must include:</span>
 
 
 
*<span style="background: #ffff00">All tests available, or at least
 
</span>
 
 
 
an executive overview of all tests available
 
 
 
*<span style="background: #ffff00">The complete, detailed list of all
 
</span>
 
 
 
tests executed for the given release of the component in question
 
 
 
*<span style="background: #ffff00">The complete, detailed result of
 
</span>
 
 
 
each executed test
 
 
 
*<span style="background: #ffff00">References to and descriptions of
 
</span>
 
  
any required 3<sup><span style="background: #ffff00">rd</span></sup><span style="background: #ffff00">
+
#Create GGUS Support Unit to receive and handle incidents (define [[FAQ GGUS-QoS-Levels|level of quality of support]])
party software necessary to execute the test plans.</span><br>
+
#Agree on [https://documents.egi.eu/document/2282 Technical Provider Underpinning Agreement] (TP UA) with EGI.eu<br>  
 +
#Subscribe to the UMD Release team mailing list
  
 
<br>  
 
<br>  
  
<span style="background: #ffff00">The test plan as described above
+
== First release<br> ==
must be made available to EGI prior to the planned release date for
 
review: </span>  
 
  
*<span style="background: #ffff00">Major release: At least 20 working
+
This section describe workflow of adding first release:&nbsp;
</span>
 
  
days  
+
#First packages are pulled into the '''untested area''' of the UMD repositories
 +
#UMD team starts the first '''verification''', involving the TP, in order to:
 +
#*understand how deployment should be done
 +
#*check the present Quality Criteria definitions and determine if the common criteria apply or not, if specific criteria are needed for the new products
 +
#*update the Verification and Staged Rollout Reports template, if needed
 +
#*provide workarounds or new versions of the packages if issues are discovered
 +
#after a '''successful verification''' packages are moved in the '''testing area '''of the UMD repos and the Early Adopter sites/sites are contacted for deploying the new release, and after a grace period of few days, to provide the '''Staged-Rollout''' report with the results of these testing phase.
 +
#*If issues are discovered – if possible workarounds will be documented, otherwise the product is '''rejected '''and a new version should be provided (fixing the issues)
 +
#After a '''successful Staged-Rollout '''packages are moved in the '''UMD Store area''', and will become part of the next available UMD release.
  
*<span style="background: #ffff00">Minor release: At least 15 working
+
<br> <br>
</span>
 
  
days
+
= Ongoing activities<br>  =
  
*<span style="background: #ffff00">Revision release: At least 10
+
Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.
</span>
 
  
working days
+
=== Software Delivery<br>  ===
  
*<span style="background: #ffff00">Emergency release: N/A</span>
+
'''Goal: Submitting new software releases'''
  
 
<br>  
 
<br>  
  
<span style="background: #ffff00">Prior to entering EGI’s Software
+
#Communicate information about new update
Provisioning Process [Błąd: Nie znaleziono źródła odwołania]
+
#*Send e-mail to URT team
and upon request of EGI’s appropriate management unit, the
+
#*Update the information on the [[URT meetings agendas|URT meeting agendas]]
Provider, in collaboration with EGI, agrees to the best of their
+
#Information needed for each update:
ability to:</span>
+
#*Product Name &amp; Version
 +
#*Release Notes as:  
 +
#**What’s New – bug fixes, new features
 +
#**Installation &amp; Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure
 +
#**List of Packages to be updated
 +
#**Location where the packages are available:
 +
#***TP repositories
 +
#***[https://appdb.egi.eu/browse/software AppDB]
  
*<span style="background: #ffff00">Rerun the complete test plan for
+
<br>
</span>
 
  
major releases
+
== '''Software Assessment'''  ==
  
*<span style="background: #ffff00">Run a subset of the tests of the
+
'''Goal: Assessment through Quality Assurance &amp; Staged Rollout '''<br>  
</span>
 
  
test plan (chosen by EGI) for minor releases
+
#Quality Assurance – through
 +
#*[[EGI Quality Criteria Definition|Quality Criteria definition ]]– definition and updates of the Quality Criteria used in the Software Verification step
 +
#*Quality Criteria Verification
 +
#**Packages are pulled from the TP repositories into UMD repos (unverified) and the Verification team starts he verification of the info provided by the TP, apply QC, general and specific defined for respective product
 +
#**A [https://documents.egi.eu/document/417 Verification Report] is provided (in DocDB) for the Staged Rollout site
 +
#**TP are informed regarding issues discovered, workarounds needed – through GGUS
 +
#[[Staged-Rollout|Staged Rollout ]]
 +
#**Successful verified products are deployed on Early Adopters sites for testing in a production environment before the inclusion in the UMD production repositories.
 +
#**Reports with the results of this testing phase are recorded in [https://documents.egi.eu/public/ShowDocument?docid=254 DocDB]
  
<br>  
+
<br>
  
== <span style="background: #ffff00">Issue management</span> ==
+
== Support ==
  
<span style="background: #ffff00">The Provider has appointed
+
Support should be provided:  
personnel for technical issues concerning the maintained software
 
components. Those technical contacts must be fully authorised to act
 
as the Provider’s representative in collaboration with EGI DMSU [Błąd: Nie znaleziono źródła odwołania]
 
regarding the triaging, assessment and resolution of any technical
 
issues concerning the software components developed and maintained by
 
the Provider.</span>
 
  
<br>
+
*via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.
 +
*(for incidents) According to declared level of [[FAQ GGUS-QoS-Levels|quality of support&nbsp;]]&nbsp;
 +
*Support is provided in '''English'''
  
=== I<span style="background: #ffff00">ssue management infrastructure</span>  ===
+
<br>
  
<span style="background: #ffff00">EGI uses GGUS for 2</span><sup><span style="background: #ffff00">nd</span></sup><span style="background: #ffff00">
+
== Information Security management  ==
level (DMSU) support. For 3</span><sup><span style="background: #ffff00">rd</span></sup><span style="background: #ffff00">-level
 
support, EGI provides the Technology Provider with a
 
provider-specific Support Unit (SU) in GGUS as 3</span><sup><span style="background: #ffff00">rd</span></sup><span style="background: #ffff00">
 
level support interface. Monitoring and reporting of provider
 
performance is implemented through this SU. </span>
 
  
<br>
 
  
=== I<span style="background: #ffff00">ssue Resolution</span>  ===
+
The following rules for information security and data protection apply:<br>•&nbsp;&nbsp;&nbsp; The Provider must define and abide by an information security and data protection policy related to the service being provided. <br>•&nbsp;&nbsp;&nbsp; This must meet all requirements of any relevant [http://www.egi.eu/about/policy/policies_procedures.html EGI policies or procedures] and also must be compliant with the relevant national legislation.<br><br>  
 
 
<span style="background: #ffff00">The Provider constructively works
 
in close collaboration with EGI DMSU on jointly investigating issues
 
raised against software components maintained by the Provider. The
 
investigation includes triaging the issue or incident, the problem
 
and any known impacts. The details of the process of collaboration
 
with the DMSU are outlined in [Błąd: Nie znaleziono źródła odwołania].</span>  
 
  
 
<br>  
 
<br>  
 
<span style="background: #ffff00">In case the triage resolves to the
 
production of a new release of the affected software component DMSU
 
and the service provider jointly agree on an Estimated Time of
 
Availability (ETA) of the necessary new release of that software
 
component. </span><br><br>
 
 
<span style="background: #ffff00">The Provider agrees to prioritise
 
the effort to resolve and fix reported issues according to their
 
priority as set in GGUS, in the following order, while respecting the
 
constraint of the agreed ETA:</span>
 
 
#<span style="background: #ffff00">Top priority</span><br>
 
#<span style="background: #ffff00">Very urgent</span><br>
 
#<span style="background: #ffff00">Urgent</span>
 
#<span style="background: #ffff00">Less Urgent</span><br>
 
 
== <span style="background: #ffff00">Vulnerability management</span>  ==
 
 
<span style="background: #ffff00">The Provider has appointed
 
personnel for vulnerability issues concerning the maintained software
 
components. Those security contacts must be fully authorised to act
 
as the Provider’s representative in collaboration with EGI SVG [Błąd: Nie znaleziono źródła odwołania]
 
and related boards regarding the triaging, assessment and resolution
 
of any vulnerability issues concerning the software components
 
developed and maintained by the Provider.</span>
 
 
<br><br>
 
 
<span style="background: #ffff00">Any appointed security contact for
 
any delivered software component must respond to any request by the
 
EGI SVG and associated groups (e.g. RAT). The response must be as
 
soon as possible, or at least within 2 working days.</span>
 
  
 
<br>  
 
<br>  
 
=== <span style="background: #ffff00">Vulnerability Resolution</span>  ===
 
 
<span style="background: #ffff00">The Provider agrees that any
 
software vulnerability found in their delivered software while
 
running on EGI production infrastructure must be handled using the
 
SVG process [Błąd: Nie znaleziono źródła odwołania]. </span>
 
 
<br><br>
 
 
<span style="background: #ffff00">The Provider agrees that any
 
software vulnerability in their delivered software found otherwise
 
must be reported to the EGI SVG. If the vulnerability is reported
 
before a fix is available, the vulnerability must be treated and
 
resolved as if found on EGI production infrastructure, i.e. it must
 
be handled using the SVG process. If the vulnerability is reported
 
after a fix is available, the Provider coordinates with SVG to make
 
available the new release including an appropriate advisory for SW
 
release on EGI production infrastructure. </span>
 
 
<br><br>
 
 
<span style="background: #ffff00">The Provider agrees to prioritise
 
vulnerability resolution according to their risk assessment, in the
 
following order:</span>
 
 
#<span id="1423728369743S" style="display: none;">&nbsp;</span><span style="background: #ffff00">Critical</span>
 
#<span style="background: #ffff00">High</span>
 
#<span style="background: #ffff00">Moderate</span>
 
#<span style="background: #ffff00">Low<span id="1423728369994E" style="display: none;">&nbsp;</span></span><br>
 
 
{| width="635" cellspacing="0" cellpadding="7"
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#'''Metric ID'''
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#'''Metric'''
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#'''Explanation'''
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.1
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of confirmed new vulnerabilities per month
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#The total number of vulnerabilities discovered in all maintained software components, whether within EGI activities or outside, are collected and published.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.2
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of fixes delivered within TD
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#<span lang="en-US">All fixes that are delivered within TD </span><span lang="en-US">''and''</span><span lang="en-US">
 
</span>
 
 
have passed the SW Rollout process are counted.
 
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.3
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of fixes delivered after TD
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#<span lang="en-US">All fixes that are delivered </span><span lang="en-US">''after''</span><span lang="en-US">
 
</span>
 
 
TD <span lang="en-US">''and''</span><span lang="en-US">
 
have passed the SW Rollout process are counted. </span>
 
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.4
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of confirmed open vulnerabilities which have exceeded the TD
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#Number of confirmed vulnerabilities, which have not been fixed and have passed the TD at the time of calculating.
 
#Current value taken at the end of the reporting month on the last working at 18:00 CE(S)T.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.5
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Total number of open vulnerabilities
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#Current value taken at the end of the reporting month on the last working day at 18:00 CE(S)T.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.6
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of requests to the Provider
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#The total number of requests for information and/or participation in investigation of issues to IGE concerning vulnerabilities.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.7
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of contact responses below 2 day target
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#Each request made by the SVG or associated boards that were not reacted upon within 2 working days are counted.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.DMSU.1
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of issues assigned to the Provider
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#The total numbers of confirmed issues that require the Provider’s effort to produce a new release are counted.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.DMSU.2
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of issues with revised ETA
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#The total number of issues for which the Provider changed the ETA are counted.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.DMSU.3
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of fixes delivered within ETA
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#<span lang="en-US">All fixes that are delivered within ETA </span><span lang="en-US">''and''</span><span lang="en-US">
 
</span>
 
 
have passed the SW Rollout process are counted.
 
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.DMSU.4
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of fixes delivered within ETA + 1 week
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#<span lang="en-US">All fixes that are delivered within ETA + 1
 
</span>
 
 
calendar week <span lang="en-US">''and''</span><span lang="en-US">
 
have passed the SW Rollout process are counted.</span>
 
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.DMSU.5
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of fixes delivered within ETA + 1 month
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#<span lang="en-US">All fixes that are delivered within ETA (+ 1
 
</span>
 
 
calendar month) <span lang="en-US">''and''</span><span lang="en-US">
 
have passed the SW Rollout process are counted.</span>
 
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.REPO.1
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of releases delivered to EGI
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#The total number of releases made available to EGI through the SW Rollout process is counted.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.REPO.2
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of releases that passed the quality criteria verification.
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#All releases that passed the quality criteria verification process are counted. Release submissions that result in changes of quality criteria applicable to the pertinent component are not counted in this metric.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.REPO.3
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of releases that passed StageRollout verification
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#All releases that passed the StageRollout phase of the SW rollout process hence are accepted for production use, are counted.
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.MISC.1
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of violations of service request response times
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#<span lang="en-US">Every occurrence of a violation of the service
 
</span>
 
 
request response times agreed to in section Błąd: Nie znaleziono źródła odwołania is counted.
 
 
#Aggregated during the reporting month.
 
 
|- valign="top"
 
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.MISC.2
 
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Number of releases that failed any mandatory Generic Documentation Quality Criterion
 
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#Documentation quality is a critical software quality criterion, but not part of the decision to accept or reject software based on technical failures.
 
#Aggregated during the reporting month.
 
 
|}
 
 
{| width="635" cellspacing="0" cellpadding="7"
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#'''Objective ID'''
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#'''Objective '''
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#'''Calculation'''
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#'''Target'''
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.SVG.1
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Proportion of issues fixed within TD
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#100 * M.SVG.2 /
 
#(M.SVG.2 + M.SVG.3 + M.SVG.4)
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.SVG.2
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Proportion of open issues beyond TD
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.SVG.4 / M.SVG.5 * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.SVG.3
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Responsiveness of security contacts to vulnerability issues
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#(M.SVG.7 / M.SVG.6) * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.DMSU.1
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Success rate of timely delivery within ETA
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#(M.DMSU.3 / M.DMSU.1) * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.DMSU.2
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Success rate of timely delivery within ETA + 1 week
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#(M.DMSU.4 / M.DMSU.1) * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.DMSU.3
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Success rate of timely delivery within ETA + 1 month
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#(M.DMSU.5 / M.DMSU.1) * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.REPO.1
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Formal quality of component releases
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#(M.REPO.2 / M.REPO.1) * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.REPO.2
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Functional quality of component releases
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#(M.REPO.3 / M.REPO.1) * 100
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#n/a
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.MISC.1
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Service response time violation
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.MISC.1
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#0
 
 
|- valign="top"
 
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#O.MISC.2
 
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#Documentation quality failure
 
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
 
#M.MISC.2
 
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
 
#0
 
 
|}
 
 
###<br><br>
 
#<span style="background: #ffff00">For any vulnerability found in any
 
</span>
 
 
software component delivered by the Provider, the Provider agrees to the best of their ability that no information about the vulnerability shall be disclosed to the public without consent of the SVG.<span style="background: #ffff00">
 
Other Software Vulnerability groups may be informed without prior
 
consent of the EGI SVG, provided they have a non-disclosure policy,
 
which is compatible with that of the EGI SVG. Also, IGE and any other
 
vulnerability groups informed must ensure that a fix is available in
 
the UMD prior to public or other widespread disclosure of the
 
vulnerability.</span>
 
 
#<br>
 
#Metrics
 
#Each metric is a positive integer number, including 0 (zero). “Secondary” metrics (i.e. metrics with an ID counter larger than 1) are constrained in that they cannot reach numbers greater than the pertinent “main” metrics (i.e. M.*.1).
 
#All metrics are collected on a monthly basis, starting on the first calendar day of the month, and ending on the respective last day of the month.
 
#<br><br>
 
#<br>
 
#Objectives
 
#Objectives are decimal numbers with a precision of 2 decimals rounded. In case of any main metric, at the point of collection, has the value 0 (zero) the related objective shall have the value “0.00%”
 
#Objectives are calculated using monthly metering of the metrics defined in section .
 
#<br><br>
 
#<br><br>
 
#Due to the expected small number of software Products contributed by IGE a sensible relation-based metering of objective targets is not possible. Instead, IGE and EGI agree that objectives undergo quarterly review collecting input across EGI management bodies and activities (SVG, RAT, DMSU, TCB, etc.) and a formal overall ratification that collected metrics are within reason.
 
#The performance of IGE in said activities will be individually reviewed and assessed on the following scale:
 
#<br>
 
#Performance above expectations
 
#<br>
 
#Performance as expected
 
#<br>
 
#Performance below expectation
 
##The review will include assessment of the past period, and expectations for the subsequent period.
 
#<br><br>
 
#
 
#<br>
 
  
 
<br>  
 
<br>  
  
[[Category:Infrastructure_Oversight]]
+
[[Category:Technology]]

Latest revision as of 10:48, 19 February 2019

Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary




EGI's UMD Provisioning activity governs and executes two main processes:

  1. Software Provisioning Process: That handles software delivery from software development teams, aka Technology Providers (TP), Quality Assurance and Reporting. 
  2. UMD Release Process: That collects tested Products per Platform and Architecture (PPAs) into UMD Releases


Of Technology Provider interest is the Software Provisioning Process, with its 3 steps:

  1. Software Delivery – Technology Providers submit new software releases
  2. Software Assessment – through Quality Assurance & Staged Rollout
  3. Reporting – inform TP about outcome of the software provisioning process


Small workflow diagram representing status of products through the Software Provisioning Process:

Software Provisioning Process.png



Initial activities - Joining UMD Release Team

To be included in UMD Release Team (URT) the interested Technology Provider should provide following information:

  1. Name of the Product team
  2. Contacts (support email address, web site address)
  3. Name and contact details of the Component Development Team Leader
  4. Description of the Component/Product and its Purpose
  5. Release channels for the product:
    • where to find the packages and their updates
    • components/products should be provided in the native packaging format of the OSs supported in UMD (i.e. as rpms for SL5 & SL6, and deb packages for Debian)
    • packages should have dependencies on packages provided by the respective OS and EPEL (for Fedora/SL family)
    • any other external dependencies should be also provided or referenced as being provided by other Technology Providers part of the URT team
  6. Documentation references – installation & configuration guides, release notes, known issues and troubleshooting, reference cards
  7. Which releases, versions, are going to be released in UMD and with which support calendar
  8. Communicate if TP have information on sites already deploying the software that can be interested in acting as Early Adopters in the staged rollout phase.

All information will be included into UMD products ID card


To send join request please read: How to join


With the help of the EGI UMD Release Team (URT), the following steps need to be performed:

  1. Create GGUS Support Unit to receive and handle incidents (define level of quality of support)
  2. Agree on Technical Provider Underpinning Agreement (TP UA) with EGI.eu
  3. Subscribe to the UMD Release team mailing list


First release

This section describe workflow of adding first release: 

  1. First packages are pulled into the untested area of the UMD repositories
  2. UMD team starts the first verification, involving the TP, in order to:
    • understand how deployment should be done
    • check the present Quality Criteria definitions and determine if the common criteria apply or not, if specific criteria are needed for the new products
    • update the Verification and Staged Rollout Reports template, if needed
    • provide workarounds or new versions of the packages if issues are discovered
  3. after a successful verification packages are moved in the testing area of the UMD repos and the Early Adopter sites/sites are contacted for deploying the new release, and after a grace period of few days, to provide the Staged-Rollout report with the results of these testing phase.
    • If issues are discovered – if possible workarounds will be documented, otherwise the product is rejected and a new version should be provided (fixing the issues)
  4. After a successful Staged-Rollout packages are moved in the UMD Store area, and will become part of the next available UMD release.



Ongoing activities

Once Technology Provider join UMD Release Team the following activities should be performed each time new version of product has been released.

Software Delivery

Goal: Submitting new software releases


  1. Communicate information about new update
  2. Information needed for each update:
    • Product Name & Version
    • Release Notes as:
      • What’s New – bug fixes, new features
      • Installation & Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure
      • List of Packages to be updated
      • Location where the packages are available:


Software Assessment

Goal: Assessment through Quality Assurance & Staged Rollout

  1. Quality Assurance – through
    • Quality Criteria definition – definition and updates of the Quality Criteria used in the Software Verification step
    • Quality Criteria Verification
      • Packages are pulled from the TP repositories into UMD repos (unverified) and the Verification team starts he verification of the info provided by the TP, apply QC, general and specific defined for respective product
      • A Verification Report is provided (in DocDB) for the Staged Rollout site
      • TP are informed regarding issues discovered, workarounds needed – through GGUS
  2. Staged Rollout
      • Successful verified products are deployed on Early Adopters sites for testing in a production environment before the inclusion in the UMD production repositories.
      • Reports with the results of this testing phase are recorded in DocDB


Support

Support should be provided:

  • via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.
  • (for incidents) According to declared level of quality of support  
  • Support is provided in English


Information Security management

The following rules for information security and data protection apply:
•    The Provider must define and abide by an information security and data protection policy related to the service being provided.
•    This must meet all requirements of any relevant EGI policies or procedures and also must be compliant with the relevant national legislation.