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 "UMDQualityCriteria"

From EGIWiki
Jump to navigation Jump to search
Line 3: Line 3:
All the software included in the Unified Middleware Distribution (UMD) must meet a set of Quality Criteria defined by EGI. The Quality Criteria can be classified into generic criteria, i.e. criteria which sould hold for any component of the UMD, and specific criteria, i.e. criteria valid for a particular component only.
All the software included in the Unified Middleware Distribution (UMD) must meet a set of Quality Criteria defined by EGI. The Quality Criteria can be classified into generic criteria, i.e. criteria which sould hold for any component of the UMD, and specific criteria, i.e. criteria valid for a particular component only.


The current Quality Criteria (QC) can be found in the EGI DocDB: [https://documents.egi.eu/secure/ShowDocument?docid=240 UMD Quality Criteria]. There are several documents that cover the different capabilities defined in the [https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap]:
Any Technology Provider (TP) willing to have their software verified by the SA2 team should carefully read them.
 
=== QC Documents ===
 
The Quality Criteria (QC) is written following the classification of capabilities defined in can the [https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap], one document for each type of capability:
* Generic QC, for all software
* Generic QC, for all software
* Functional Capabilities QC
* Functional Capabilities QC
Line 9: Line 13:
* Operational Capabilities QC
* Operational Capabilities QC


TP willing to have their software audited by the SA2 team should carefully read them.
Take into account that a software component may cover QC specified in more than one of those documents.
 
== QC drafts ==
 
This page is now used as a placeholder for drafting new criteria for components.
 
=== Identified Capabilities ===
These capabilities are identified in the [https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap] but still waiting for EGI Community input for definition:
 
==== Functional Capabilities ====
* File Encryption/Decryption


: Sensitive data needs to be stored securely. Before being stored in a remote file store the file may need to be encrypted and then on retrieval de-encrypted before use. The capability should also provide solutions relating to the storage of the keys needed to perform these tasks.
== QC Roadmap ==


* Metadata Catalogue
QC definition is a continuous process driven by the requirements of users and operations communities, however the verification of new software releases will be done against fixed releases of the QC documents. At least every 6 months a new version of the QC will be released, although more frequent releases may occur if necessary. Each new release of the QC will be announced in this page and through the TCB mailing list. Along with the announcement of each release of QC specification, a date for its use in verification will be specified. It is expected that verification will use new releases of the QC within 2 to 4 weeks from the release date.
: The metadata catalogue is used to store and query information relating to the data (files, databases, etc.) stored within the production infrastructure.  


* Database Access
Each QC release will contain documentation with:
: Many communities are moving to the use of structured data stored in relational databases. These need to be accessible for controlled use by remote users as any other e-Infrastructure resource.
* major changes introduced in the version.
* deprecated criteria, if there is any.
* criteria to be deprecated in next release of the QC, if any.


* File Transfer Scheduling
=== Current QC Specification ===
: The bandwidth linking resource sites is a resource that needs to be managed in the same way compute resources at a site are accessed through a job scheduler. By being able to schedule wide area data transfers, requests can be prioritised and managed. This would include the capability to monitor and restart transfers as required.


* Remote Instrumentation
<blockquote style="border-width:1px; border-style:solid; padding:0.2em;background-color:#FFFFCC">
: Instruments are data sources frequently encountered within e-Infrastructures. As part of a distributed computing architecture providing remote access to manage and monitor these instruments is becoming increasingly important within some communities.
In the current stage, a first complete version of Quality Criteria that covers for UMD software is undergoing. It is expected that this comprehensive QC for all components will be available on '''early February 2011'''. Drafts of these QC is available at DocDB: [https://documents.egi.eu/public/ShowDocument?docid=240 QC document].
</blockquote>


* Workflow
=== Future Releases ===
: The ability to define, initiate, manage and monitor a workflow is a key capability across many user communities. It is also a capability that can be deployed by a user or a user community (i.e. it does not need to be a service provided as part of the core infrastructure) but the various workflow systems may have requirements that need to be supported within the core infrastructure.


==== Operational Capabilities ====
{| class="wikitable sortable"  style="border:1px solid black" cellspacing="0" cellpadding="3" border="1"
* Virtual Image Management
|- style="background:Lightgray"  align="left"
: As virtual machine images become the default approach to providing the environment for both jobs and services, increased effort is needed on building the trust model around the distribution of images. Resource providers will need a mechanism for images to be distributed, cached and trusted for execution on their sites.  
! DocDB link
! Expected Release Date
! Expected Verification Date
! More information
|-
| [https://documents.egi.eu/public/ShowDocument?docid=240 240]
| 01. 02. 2011
| 01. 02. 2011
| [[EGI-InSPIRE:UMDQualityCriteria:QC1 | release notes]]
|-
| -
| 01. 08. 2011
| 15. 08. 2011
| -
|}


* Virtual Machine Management
=== Past QC releases ===
: The core functionality is for authorized users to manage the virtual machine life-cycle and configuration on a remote site (i.e. start, stop, pause, etc.) Machine images would be selected from a trusted repository at the site that would be configured according to site policy. Together this would allow site managers to determine both who could control the virtual machines running on their sites and who generated the images used on their site.


* Messaging
There are no past QC releases.
: Within distributed systems, a message ‘bus’ provides a reliable mechanism for data items to be sent between producers and (multiple) consumers. Such a capability, once established, can be reused by many different software services.


[[Category:WP5-SA2]]
[[Category:WP5-SA2]]

Revision as of 13:47, 9 December 2010

UMD Quality Criteria

All the software included in the Unified Middleware Distribution (UMD) must meet a set of Quality Criteria defined by EGI. The Quality Criteria can be classified into generic criteria, i.e. criteria which sould hold for any component of the UMD, and specific criteria, i.e. criteria valid for a particular component only.

Any Technology Provider (TP) willing to have their software verified by the SA2 team should carefully read them.

QC Documents

The Quality Criteria (QC) is written following the classification of capabilities defined in can the UMD RoadMap, one document for each type of capability:

  • Generic QC, for all software
  • Functional Capabilities QC
  • Security Capabilities QC
  • Operational Capabilities QC

Take into account that a software component may cover QC specified in more than one of those documents.

QC Roadmap

QC definition is a continuous process driven by the requirements of users and operations communities, however the verification of new software releases will be done against fixed releases of the QC documents. At least every 6 months a new version of the QC will be released, although more frequent releases may occur if necessary. Each new release of the QC will be announced in this page and through the TCB mailing list. Along with the announcement of each release of QC specification, a date for its use in verification will be specified. It is expected that verification will use new releases of the QC within 2 to 4 weeks from the release date.

Each QC release will contain documentation with:

  • major changes introduced in the version.
  • deprecated criteria, if there is any.
  • criteria to be deprecated in next release of the QC, if any.

Current QC Specification

In the current stage, a first complete version of Quality Criteria that covers for UMD software is undergoing. It is expected that this comprehensive QC for all components will be available on early February 2011. Drafts of these QC is available at DocDB: QC document.

Future Releases

DocDB link Expected Release Date Expected Verification Date More information
240 01. 02. 2011 01. 02. 2011 release notes
- 01. 08. 2011 15. 08. 2011 -

Past QC releases

There are no past QC releases.