Bug 1041730 - [RFE][cinder]: Add validation hooks for volume type extra specs
Summary: [RFE][cinder]: Add validation hooks for volume type extra specs
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/cind...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 18:51 UTC by RHOS Integration
Modified: 2015-11-20 19:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:40:23 UTC
Target Upstream Version:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.