Bug 1041730

Summary: [RFE][cinder]: Add validation hooks for volume type extra specs
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/cinder/+spec/volume-type-validation
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:40:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 18:51:57 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/volume-type-validation.

Description:

When adding/setting volume type extra spec key/values, we should allow the volume backend specified in volume_backend_name, to be given a chance to validate the key/value being set.   This is a simple sanity check for the administrator setting/updating the extra spec key/value.   

Use case:
  For example, the 3PAR driver has many options it can accept for extra specs on a volume.  One of those settings is the 'hp3par_cpg' extra spec key.  A 3PAR CPG is a pool of available space to provision volumes. 

1) An administrator creates a volume type called "Gold"
2) The administrator sets the 'volume_backend_name' value for the Gold volume type to point to the 3PAR iscsi driver defined in the cinder.conf
3) The administrator adds/sets the 'hp3par_cpg' extra spec key with a value of 'MySSDRaid1CPG'.

Result:
  Since the volume_backend_name is specified, cinder would know which driver to call to request validation for the hp3par_cpg key.  The 3PAR driver's validate method would be called, and it would see if the 'MYSSDRaid1CPG' exists on the 3PAR it's configured to manage.  If the CPG exists, it returns a success, if the CPG doesn't exist it would raise an Exception saying that the CPG doesn't exist.   The cinder command line tool would puke out an error with the contents of the Exception message.   The extra spec key is NOT set in the database at this point, because it's invalid.

This lets the administrator right then, that the value for the hp3par_cpg key is invalid, and the extra spec key isn't in the volume type.


Issues:
  If there is no volume_backend_name specified at the time the admin sets the extra spec key, then no validation call to a driver can't happen.  Cinder doesn't know which backend to call.  


Workaround:
   The workaround for the lack of validation today is to:
1) create the volume type
2) add the extra spec keys/values
3) try and create a volume.   If it works, you know the keys are mostly valid.   Some extra spec keys/values may only be used at volume attach time.  The 3PAR driver has a extra spec key of 'hp3par_persona', which is only used at volume attach time.  

Specification URL (additional information):

None