Jump to: navigation, search

Heat/param validators

As an extenstion to the current CFN compatable parameter declarations, also support an extended, declaritive, and (eventually) pluggable parameter declaration syntax called "constraints". Note: these examples also use the proposed "inputs" alternative tag for Parameters proposed here, but that is not required for this proposal.

Example
inputs:
  flavor:
    description: WebServer instance type
    type: String
    default: "m1.large"
    # constraints validate input values prior to provisioning
    constraints:
    # maps to an instance of heat.options.constraint.Choice
    - type: Choice
      description: must be a valid instance type
      values:
      - t1.micro
      - m1.small
      - m1.large
      - m1.xlarge
      - m2.xlarge
      - m2.2xlarge
      - m2.4xlarge
      - c1.medium
      - c1.xlarge
      - cc1.4xlarge
  min_servers:
    type: Number
    description: minimum number of servers to have active
    constraints:
    - type: Range
      min: 2
      max: 10
      description: must have between 2 and 10 servers active by default
  db_name:
    default: mydb
    description: The database name
    type: String
    constraints:
    - type: Len
      min: 1
      max: 64
      description: database name must be between 1 and 64 characters
    - type: Matches
      pattern: "[a-zA-Z][a-zA-Z0-9]*"
      description: database name must begin with a letter and contain only alphanumeric characters.
    

At parse time, a list of associated constraint instances would be attached to each input and each constraint evaluated prior to performing any provisioning. Inputs/Parameters may have multiple attached constraints and all constraints for each input would be evaluated and errors reported in the same manner as the existing validation attributes. These constraints are not mutually exclusive with the current property validation mechanisms and a template that specifies both for an input will have both traditional as well as constraint validation performed.

Initially, constraint equivalents for the current validation would be developed and documented: No String constraint. A regular expression that represents the patterns allowed in the parameter's string value. No String constraint. A integer value that determines the largest number of characters in the parameter's string value. MinLength No String constraint. A integer value that determines the smallest number of characters in the parameter's string value. MaxValue No Number constraint. A numeric value that determines the largest numeric value allowed for the parameter. MinValue No Number constraint. A numeric value that determines the smallest numeric value allowed for the parameter.

CFN Parameter property Constraint Class Description
AllowedValues Choice Restricts input values to listed options
AllowedPattern Matches Restricts input value to matching the provided expression
MaxLength, MinLength Len Restricts input value length to be within the specified boundaries
MaxValue, MinValue Range Restricts numeric input values to be within the specified boundaries

Follow on blueprints will be created to support:

  • a constraint that restricts input values to an available glance image
  • a constraint that restricts input values to an available nova flavor
  • constraint plug-ins