[nova][ptg] Summary: Extra specs validation
Spec: https://review.openstack.org/#/c/638734/ Summary: Schema for syntactic validation of flavor extra specs, mainly to address otherwise-silently-ignored fat-fingering of keys and/or values. Agreements: - Do it in the flavor API when extra specs are set (as opposed to e.g. during server create) - One spec, but two stages: 1) For known keys, validate values; do this without a microversion. 2) Validate keys, which entails - Standard set of keys (by pattern) known to nova - Mechanism for admin to extend the set for snowflake extra specs specific to their deployment / OOT driver / etc. - "Validation" will at least comprise messaging/logging. - Optional "strict mode" making the operation fail is also a possibility. efried .
On 5/2/2019 11:11 PM, Eric Fried wrote:
- Do it in the flavor API when extra specs are set (as opposed to e.g. during server create) - One spec, but two stages: 1) For known keys, validate values; do this without a microversion. 2) Validate keys, which entails - Standard set of keys (by pattern) known to nova - Mechanism for admin to extend the set for snowflake extra specs specific to their deployment / OOT driver / etc. - "Validation" will at least comprise messaging/logging. - Optional "strict mode" making the operation fail is also a possibility.
I don't remember agreeing to one spec with two stages for this. If you want to get something approved in workable in Train, validating the values for known keys is low-hanging-fruit. Figuring out how to validate known keys in a way that allows out of tree extra specs to work is going to be a lot more complicated and rat-holey, so I would personally make those separate efforts and separate specs. -- Thanks, Matt
participants (2)
-
Eric Fried
-
Matt Riedemann