b245225d5e
Modifying a Volume Type doesn't actually update any volumes that are currently using said Volume Type. Given that this is an admin only operation it was never really too much of a concern. There has been some issues reported however where an admin modified the type while volumes were using it, then ran into problems becuase the volumes didn't have the expected settings described by the type. This change adds a check before updating/deleting extra-specs of a volume type. If there are any volumes currently assigned to the type being modified/deleted the operation will fail with an InvalidRequest immediately when attempting the call. To maintain backward compatability incase someobdy is using this for something and they are really really sure they want to continue doing so, we also add a config option to allow the old behavior but default to NOT allowing it: 'allow_inuse_volume_type_modification=False' APIImpact Change-Id: Iaea721e13a3903cae60cc3fb3acfad03bd173a6b Closes-Bug: #1667071
14 lines
751 B
YAML
14 lines
751 B
YAML
---
|
|
fixes:
|
|
- Modifying the extra-specs of an in use Volume Type was something that
|
|
we've unintentionally allowed. The result is unexpected or unknown
|
|
volume behaviors in cases where a type was modified while a volume was
|
|
assigned that type. This has been particularly annoying for folks that
|
|
have assigned the volume-type to a different/new backend device.
|
|
|
|
In case there are customers using this "bug" we add a config option to
|
|
retain the bad behavior "allow_inuse_volume_type_modification", with a
|
|
default setting of False (Don't allow). Note this config option is being
|
|
introduced as deprecated and will be removed in a future release. It's
|
|
being provided as a bridge to not break upgrades without notice.
|