Parameter Constraints

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(
             properties.Schema.STRING,
             'Glance image ID or name.',
            constraints=[
                constraints.CustomConstraints('glance.image')
            ]

And then remove the custom call in Resource.validate.

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

parameters:
    database_image:
       type: string
       description: The image to use for the database instances
       constraints:
          - 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.

https://github.com/therve/heat/tree/custom-constraints-spike 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: https://review.openstack.org/#q,topic:bp/param-constraints,n,z

Addressed by: https://review.openstack.org/66304
    Make context available during constraint validation

Addressed by: https://review.openstack.org/70318
    Implement custom constraints

Addressed by: https://review.openstack.org/70319
    Add a nova keypair constraint

Addressed by: https://review.openstack.org/71295
    Enable usage of custom constraint in parameters

Gerrit topic: https://review.openstack.org/#q,topic:bp/glance-parameter-constraint,n,z