VMIC Use Cases and Requirements

Models

Early design draft

• HEPiX_VWG_-_Image_Distribution_-_Draft_.pdf: Image Distribution (Draft)

CERN alternate model

slides

comments received

• the usage of VMIC for all instances was found to be confusing. It was proposed by OS to distinguish between a Site-VMIC (SVMIC) and an Endorser VMIC (EVMIC).
• implementation wise this difference may not be relevant

VM life cycle

1. VMI creation
2. VMI endorsement + publication
3. VMI distribution (between sites)
4. VMI verification
5. VMI approval
6. VMI distribution (within each site)
7. VMI revocation

Definitions

Use Cases

1. Endorser handling:
------------------
1.1   A new Endorser for VO XYZ enters. 
1.1.1 All sites supporting VO XYZ must be informed
1.1.2 The new endorser needs to be approved
1.1.3 All sites supporting VO XYZ are asked to make his images available for the users of this VO

1.2   An Endorser leaves VO XYZ and is not replaced 
1.2.1 The VO desides to revoke all his images 
1.2.2 The VO wants the sites to keep running  his images
1.2.3 All sites supporting VO XYZ must be informed about this change. No NEW images of this Endorser must be approved 

1.3   An Endorser E1 of VO XYZ is replaced by Endorser E2

1.4   VO A elects a new Endorsers E1. Site S1 supports VO A. Site S2 does not support VO A  
1.4.1 Site S1 needs to take action
1.4.2 Site S2 should not be bothered 

1.5   An Endorser becomes unavailable for an extended period
1.5.1 Endorser is ill, or on holidays
1.5.2 The site hosting his VMIC becomes unavailable


2. Endorser actions:
  -----------------
2.1   A new image is released. Endorser A blesses it for publication
2.1.1 Sites add the new image 
2.1.2 Supporting Sites are asked to make the new  image available for the users
2.2   Endorser A revokes a previously blessed images, eg because a bug has been found, without replacing it
2.3   Endorser A wants to update an existing image

3. Site actions:
  -------------
3.1   A site B wants to use a site specific image for local users
3.2   A site B has created an images which is useful for other sites and wants to share it
3.3   A site is asked to run an image from a trusted endorsers, and the site policies allow this
3.3.1 the image integrity is ok, and the image can be made available
3.3.2 the image integrity is violated (eg. wrong checksum, wrong signature ...)
3.4   A site is asked to run an image from a trusted endorser, but site policies forbid them to run it
3.5   A site needs to stop running images for type XYZ because of some reason (security, bug, wrong software,changed site policies)
3.6   A site needs to stop running all images of Endorser XYZ, which were previously trusted and used
3.7   A site needs to make a new image available to their users
3.8   Endorser A is replaced by Endorser B. Images of A are no longer trusted, Images of Endorser B are trusted.

Model testing

Original design

CERN proposed alternative model

1. Endorser handling

Notes: 
 - Each endorser runs his own VMIC. 
 - Endorsers can be associated to 
   + a site (side endorser)
   + a VO   (VO endorser)

1.1: A new Endorser for VO XYZ enters
-------------------------------------
 * The endorser sets up his VMIC
 * The endorser VMIC gets listed in the VOs list of endorsers
1.1.1
 * The change gets announced to the sites supporting this VO
1.1.2
 * The sites decide to update their local list of endorsers or not
 * The sites get the list of images of this new endorser from the endorsers VMIC
1.1.3
 * The sites start the local approval procedure for the images of this endorser

1.2: An Endorser leaves VO XYZ and is not replaced 
--------------------------------------------------
1.2.1: The VO desides to revoke all his images 
 * The endorser is removed from the VOs list of endorsers
 * The endorsers VMIC is destroyed
 * The sites supporting this VOs are informed of the change by the VO
 * The sites update their local list of endorsers
 * The sites ensure that local copies of all affected images are revoked
1.2.2:  The VO wants the sites to keep running  his images
 * in this case the VO must provide a new endorser who re-endorses the images, case 1.3
1.2.3: As the endorsers VMIC has been destroyed, no new images can be released by this person

1.3: An Endorser E1 of VO XYZ is replaced by Endorser E2
--------------------------------------------------------
 * The VO follows step 1.1 to support the new endorser, and  then 1.2 to revoke the old one

1.4: VO A elects a new Endorsers E1. Site S1 supports VO A. Site S2 does not support VO A  
---------------------------------------------------------
1.4.1, 1.4.2
 * implicitly fulfilled as the VO only contacts those sites which support it
 
2. Endorser actions
===================
2.1  A new image is released. Endorser A blesses it for publication
-------------------------------------------------------------------
 * The endorser adds the image to his VMIC

 a/ sites regularly poll the VMICs of all endorsers in their local endorser list for updates
 b/ VOs can ask sites to perform this check outside the normal intervals
 * sites start the local approval procedure to make the image available

2.1.1, 2.1.2.fulfilled by construction

2.2 Endorser A revokes a previously blessed images, eg because a bug has been found, without replacing it
----------------------------------------------
 * The endorser removes these images from his VMIC
 * sites regularly poll the VMICs in their local endorser list
 * VOs can ask sites to poll outside the regular interval 
 * sites remove all images which are no longer in the VMICs from their local list of approved images

2.3 Endorser A wants to update an existing image
-----------------------------------------------
 * The endorser adds the new image to his VMIC
 * The endorser removes the old image from his VMIC
 * sites regularly poll the VMICs in their local endorser list, and revoke support for all images which may have disappeared from the VMICs
 * VOs can ask sites to poll outside the regular interval 
 * sites decide on the approval of the updated image, and add the image to their list of approved images
 * sites remove all images which are no longer in the VMICs from their local list of approved images

3. Site actions
===============
3.1 A site B wants to use a site specific image for local users
--------------------------
 * the site's local endorser endorsed the image
 * the site approves it's own image
 * the image is added to the sites list of approved images

3.2 Site B has created an image which is useful for other sites and wants to share it
---------------------------
 * the site's endorser adds the image to his VMIC
 * remote sites supporting this endorser will pick up the image during regular update checks
 * the remote sites launch their local approval procedure
 * the remote sites add the new image to their local list of approved images (or not)

3.3 A site is asked to run an image from a trusted endorsers, and the site policies allow this
------------------------------
 * implicitely handled

3.4  A site is asked to run an image from a trusted endorser, but site policies forbid them to run it
-----------------------------------------------------------------
 * implicietely handled. The site does not approve the image and does not add it to it's local list of approved images

3.5 A site needs to stop running images for type XYZ because of some reason (security, bug, wrong software,changed site policies)
---------------------------------------------
 * the site gets notified by an external instance of the problem
 * the site checks the meta data information of the images in their local list of approved images
 * the site flags image for removal based on their meta data
 * the site removes the affected images from their local list of approved images
 * in case of a VO, the affected VO is informed
 * the VO proceeds as described above for the revokation of the image

3.6 A site needs to stop running all images of Endorser XYZ, which were previously trusted and used
--------------------------------
 * The endorser wil have disappeared from the list of trusted endorsers
 * images of this endorser get removed from the local list of approved images

3.7 A site needs to make a new image available to their users
---------------------------------
 * The image has been added upstream and appears in one of the VMICs 
 * At the next poll, or on request of the VO, the approval procedure is started
 * the image is added or not to the local list of approved images

3.8 Endorser A is replaced by Endorser B. Images of A are no longer trusted, Images of Endorser B are trusted.
----------------------------------
 * see 1.3

Requirements

Comments.

• Next, the use cases above are to be used to derive requirements which will be used for the final design decision.
• The requirements are split into two types SVMIC (site VM image catalog) and EVMIC (endorser VM image Catalog)

Customer Requirements

Deployment SVMIC

• Suitable for deployment at all sites from Tier 3 to tier 0 sites.
• At Tier 3 sites should be 100% open source.
• At Tier 1 sites should be fault tolerant and support fall over.

Deployment EVMIC

• Suitable for deployment by an individual.
• Require minimal support effort.

Mission profile SVMIC

• Required to check validity of image for each node instantiation. Nodes are instantiated either per day for sites using CERN model or per job like Sara and PIC.
• Required to query each EVMIC to check images are valid and cascade effect.
• Site can authorize or de authorise EVMIC.
• Must keep a complete history for Image to EVMIC and so endorser for all instantiations.

Mission profile EVMIC

• Add images to EVMIC with tag.
• Revoke EVMIC images.
• Provide interface for SVMIC to query endorsed images.

Performance and related parameters SVMIC

Per Job requests must be fast. Sites that instantiate images per jobs will need to operate at an estimated rate of 100 requests per second. These requests will be,

• Get image ID by (vo,tag).
• Get image location by ID.
• Check image validity by ID.

Other requests will be slower.

• Check EVMIC for expired updated images.
• Site blocking of images.
• Site blocking of endorser.

Performance and related parameters EVMIC

The EVMIC will have no strong performance requirements. These will be mearly that the service can support 400 SVMIC's querying the endorsed image list 3-4 times a day.

Utilization environments SVMIC

• The SVMIC will be used by the admin to control images used at their site.
• Sites will trust and remove trust from endorsers. When Endorsers are trusted they will be able to add trusted images.
• Sites will trust and remove trust from Images.
• Sites will be able to request all uses of Images.
• Sites will be able to list all currently trusted images and their associated images.
• The SVMIC will be used as a persistent store for downloading images from Endorsers.

Utilization environments EVMIC

• Endorsers will add images and check sums.
• Endorsers will add and remove tags to images.
• Endorsers will remove endorsement of images.

Effectiveness requirements SVMIC.

• The SVMIC will have to stay up at all times.
• The SVMIC will have to be automatically configured.

Effectiveness requirements EVMIC.

• The EVMIC will have to be easy to deploy and configure.

Operational life cycle SVMIC.

• The service will have to run 24/7 without restarts.

Operational life cycle EVMIC.

• This service may come and go periodically.
• Up time requirements cannot be specified to high as Endorsers will be put off by the requirements.

Environment SVMIC.

• Expected running on a dedicated box or VM.
• Teir 1 sites may expect a fall over environment with fault tolerance.

Environment EVMIC.

• Expected to run on a shared host or web site with security extensions.

Left as a template for further requirements addition.

Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top level functions for functional analysis.[1]

Non-functional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

Performance Requirements

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of critically to system success, and their relationship to other requirements.[1]

Design Requirements

The \u201cbuild to,\u201d \u201ccode to,\u201d and \u201cbuy to\u201d requirements for products and \u201chow to execute\u201d requirements for processes expressed in technical data packages and technical manuals.[1]

Derived Requirements

Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.[1]

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.[1] Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard.

Related information

Policy document (draft)

http://www.jspg.org/wiki/Policy_Trusted_Virtual_Machines

-- UlrichSchwickerath - 18-Jun-2010