Parameter Constraints

Registered by Randall Burt

As an extenstion to the current CFN compatable parameter declarations, also support an extended, declaritive, and (eventually) pluggable parameter declaration syntax called "constraints"

Blueprint information

Randall Burt
Needs approval
Thomas Herve
Series goal:
Accepted for icehouse
Milestone target:
milestone icon 2014.1
Started by
Thomas Herve
Completed by
Thomas Herve

Related branches



This is what the resource.validate() is for. You override that and you can check for dynamic things like:
does the image/flavor exist.

(randallburt) yes, this proposes an extension to the validation mechanism to allow for the addition of new validators without having to change code in individual resources and extended validation of inputs outside of / prior to resource validation. The idea is that eventually, these could be handled as plugins as with resources. Once you code a validator, any param/input that they're attached to get the validation without having to change the code in inputs.

(ttx) You should set a milestone target if you want it considered for havana.

(asalkeld) I am starting to need this for template resources.
I started off thinking the plugin model was cool until I realized that would suck for end users as
it doesn't give them a mechanism to have better validation for resource templates that don't all
ready exist. I agree the plugin model will still be good for things like zones/regions,flavors.

I am coming to the conclusion that the property and parameter constraints need to be the same.
we need list, and nested schema.

(therve) My proposal would be to have a registry of constraints the same way we have a registry of resources, so that you can reuse validation in properties and parameters. You could declare for example in the Server resource:

         image_type: properties.Schema(
             'Glance image ID or name.',

And then remove the custom call in Resource.validate.

Once we have the same schema in parameters, you could reuse it a template:

       type: string
       description: The image to use for the database instances
          - type: glance.image

One tricky bit is that to be able to validate those type of constraints, API calls need to be made and thus require the authorization credentials of the user. The easiest way is to pass down the request context when available. contains a spike showing the rough idea (although there constraints are just function, whereas there should probably be objects to have custom messages).

Gerrit topic:,topic:bp/param-constraints,n,z

Addressed by:
    Make context available during constraint validation

Addressed by:
    Implement custom constraints

Addressed by:
    Add a nova keypair constraint

Addressed by:
    Enable usage of custom constraint in parameters

Gerrit topic:,topic:bp/glance-parameter-constraint,n,z


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.