HOT parameter validation

Registered by Thomas Spatzier

This blueprint is to address full parameter validation based on the current HOT hello world implementation. HOT will use an enhanced syntax for defining parameters constraints - partly taken from proposal discussed at [1] - which will be implemented by this blueprint.

Goal is to have feature equivalance with cfn parameter validation, plus addtional enhanced features (e.g. multiple regular expressions, specific validation message per constraint, etc.).

As part of this blueprint we also plan to provide an enhanced HOT sample template, as well as documentation of the parameter validation syntax.


Blueprint information

Steve Baker
Thomas Spatzier
JunJie Nan
Series goal:
Accepted for havana
Milestone target:
milestone icon 2013.2
Started by
JunJie Nan
Completed by
JunJie Nan


Here is a sample to show the parameter constraints syntax for HOT, inspired by [1]. The processing of this syntax will be enabled by the blueprint.

heat_template_version: 2013-05-23

    type: string
    description: sample parameter to show parameter constraints for strings
    default: sample
    hidden: true
      - allowed_values: [sample, othersample, and_one_more]
        description: >
          Value must be one of sample, othersample or and_one_more
      - allowed_pattern: "[a-zA-Z]+"
        description: Value must consist of characters only
      - allowed_pattern: "[a-z]+[a-zA-Z]*"
        description: Value must start with a lowercase character
      - length: { min: 4, max: 10}
        description: Length must be between 4 and 10 characters
    type: number
    description: sample parameter to show parameter constraints for numbers
    default: 1
      - allowed_values: [1, 2, 4, 8]
        description: Value must be either 1, 2, 4 or 8
      - range: { min: 1, max: 8}
        description: Value must be between 1 and 8 characters

Explanation of some elements:
hidden: true | false -> covers cfn NoEcho setting; default (if omitted) is false

constraints is an array of the single constraints. There can be multiple constraints of a type. For example, there can be multiple 'allowed_pattern' constraints to allow users to split complicated regexes into smaller pieces.
There should be one constraint description for each single constraint, which allows for giving the user precise feedback.

Contraint types and mapping to cfn constraints:
allowed_values -> cfn AllowedValues
allowed_pattern -> cfn AllowedPattern
lengh (with min and max settings) -> cfn MinLength and MaxLength
     min and max are option, but one must be given
range (with min and max settings) -> cfn MinValue and MaxValue for numbers
     min and max are option, but one must be given

(thomas-spatzier) 20130722:
Removed 'constraints_description' attribute that would have given a default message for all constraints. Let's have template authors provide a good message for each single constraint.

Gerrit topic:,topic:bp/hot-parameters,n,z

Addressed by:
    HOT parameter validation model translation

Addressed by:
    Hot parameter validator

Addressed by:
    Fix test cases using dict as template or schema directly

Addressed by:

Addressed by:
    Fix test cases pass dict as template object directly.

Addressed by:
    Do validation in schema object


Work Items

Work items:
Model translation: DONE
Hot Parameter Validation: INPROGRESS

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.