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

From EGIWiki
Jump to navigation Jump to search
(Created page with '== QC Release Notes == === Non Covered Capabilities === These capabilities are identified in the [https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap] but still w…')
 
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
== QC Release Notes ==
== QC Release Notes ==


=== Non Covered Capabilities ===
{{Template:Block-comment
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, therefore they will not be included in the QC.
| name=Warning
| text=These QC documents are already deprecated, check [[EGI Quality Criteria Dissemination]] and [[EGI Quality Criteria Verification]] pages that contain the latest information.
}}
 
These release notes describe the first release of the Quality Criteria for UMD software that is expected to be delivered in early February 2011.
 
=== Documents ===
The Quality Criteria (QC) can be found in the [https://documents.egi.eu/public/ShowDocument?docid=240 QC Specification document], there is one document for each type of capability:
 
* Generic QC, for all software
* Security Capabilities QC
* Information Capabilities QC
* Storage Capabilities QC
* Data Capabilities QC
* Compute Capabilities QC
* Operations Capabilities QC
 
Take into account that a software product may cover QC specified in more than one of those documents.
 
=== Deprecated QC ===


==== Functional Capabilities ====
None
* 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.
=== Covered Capabilities ===
From all capabilities identified in version 2 of [https://documents.egi.eu/document/272 UMD Roadmap], the following are covered:
==== Security Capabilities ====
* Authentication
* Attribute Authority (using [https://twiki.cern.ch/twiki/bin/view/EMI/VOMS VOMS] as reference implementation)
* Authorization (using [https://twiki.cern.ch/twiki/bin/view/EMI/Argus Argus] as reference implementation)
* Credential Management (using [http://grid.ncsa.illinois.edu/myproxy/ MyProxy] as reference implementation)


* Metadata Catalogue
==== Information Capabilities ====
: The metadata catalogue is used to store and query information relating to the data (files, databases, etc.) stored within the production infrastructure.
* Information Model
* Information Discovery


* Database Access
==== Storage Capabilities ====
: 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.
* File Encryption/Decryption (using [https://twiki.cern.ch/twiki/bin/view/EGEE/DMEDS Hydra] as reference implementation)
* File Access
* File Transfer
* File Transfer Scheduling (using [https://twiki.cern.ch/twiki/bin/view/EMI/EMIFileTransferSchedulingCapability FTS] as reference implementation)
* Storage Management


* File Transfer Scheduling
==== Data Capabilities ====
: 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.
* Data Access (using [http://www.ogsadai.org.uk/ OGSA-DAI] as reference implementation)
* Metadata Catalogue (using [https://twiki.cern.ch/twiki/bin/view/EMI/AMGA AMGA] and [https://twiki.cern.ch/twiki/bin/view/LCG/DataManagementTop#LFC_and_DPM LFC] as reference implementations)


* Remote Instrumentation
==== Compute Capabilities ====
: 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.
* Job Execution
* Parallel Job
* Job Scheduling (using [http://web.infn.it/gLiteWMS/ WMS] as reference implementation)


* Workflow
==== Operations Capabilities ====
: 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.
* Monitoring
* Accounting (using [https://twiki.cern.ch/twiki/bin/view/EMI/APELClient APEL] as reference implementation)


==== Operational Capabilities ====
=== Non Covered Capabilities ===
* Virtual Image Management
Several capabilities identified in the UMD Roadmap are still missing the Quality Criteria due to lack of a clear reference implementation or missing requirements from the EGI community. Most of the missing capabilities are introduced in the last UMD roadmap version.
: 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.  


* Messaging
* Interactive Job Management
* Workflow
* Virtual Machine Management
* Virtual Machine Management
: 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.
* Virtual Machine Image Format
* Image Distribution
* Remote Instrumentation
* Client API


* Messaging
The Quality Criteria Task will continue the process of defining the missing capabilities for the next release of the QC.
: 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.

Latest revision as of 23:09, 24 December 2014

QC Release Notes

Warning:
These QC documents are already deprecated, check EGI Quality Criteria Dissemination and EGI Quality Criteria Verification pages that contain the latest information.


These release notes describe the first release of the Quality Criteria for UMD software that is expected to be delivered in early February 2011.

Documents

The Quality Criteria (QC) can be found in the QC Specification document, there is one document for each type of capability:

  • Generic QC, for all software
  • Security Capabilities QC
  • Information Capabilities QC
  • Storage Capabilities QC
  • Data Capabilities QC
  • Compute Capabilities QC
  • Operations Capabilities QC

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

Deprecated QC

None

Covered Capabilities

From all capabilities identified in version 2 of UMD Roadmap, the following are covered:

Security Capabilities

  • Authentication
  • Attribute Authority (using VOMS as reference implementation)
  • Authorization (using Argus as reference implementation)
  • Credential Management (using MyProxy as reference implementation)

Information Capabilities

  • Information Model
  • Information Discovery

Storage Capabilities

  • File Encryption/Decryption (using Hydra as reference implementation)
  • File Access
  • File Transfer
  • File Transfer Scheduling (using FTS as reference implementation)
  • Storage Management

Data Capabilities

  • Data Access (using OGSA-DAI as reference implementation)
  • Metadata Catalogue (using AMGA and LFC as reference implementations)

Compute Capabilities

  • Job Execution
  • Parallel Job
  • Job Scheduling (using WMS as reference implementation)

Operations Capabilities

  • Monitoring
  • Accounting (using APEL as reference implementation)

Non Covered Capabilities

Several capabilities identified in the UMD Roadmap are still missing the Quality Criteria due to lack of a clear reference implementation or missing requirements from the EGI community. Most of the missing capabilities are introduced in the last UMD roadmap version.

  • Messaging
  • Interactive Job Management
  • Workflow
  • Virtual Machine Management
  • Virtual Machine Image Format
  • Image Distribution
  • Remote Instrumentation
  • Client API

The Quality Criteria Task will continue the process of defining the missing capabilities for the next release of the QC.

Retrieved from "https://wiki.egi.eu/w/index.php?title=UMDQualityCriteria_QC1&oldid=73441"