Inputs

inputs are parameters that are injected into a blueprint when a deployment is created. These parameters can be referenced by using the get_input intrinsic function.

Inputs are useful when there is a need to inject parameters in the blueprint that were unknown when the blueprint was created, and they can be used for distinction between different deployments of the same blueprint.

Declaration

inputs:

  input1:
    ...
  input2:
    ...

Schema

Note: display key is valid only for inputs of type textarea, it can contain only a number of rows to be used to display the field. See the example below.

Note: if you specify a custom data_type in the type field, a property validation will occur. See the example below.

Example

inputs:

  image_name:
    description: The image name of the server
    type: string
    default: "Ubuntu 12.04"

  extra_vm_details:
    description: Extra server details
    default:
      key_name: 'my-openstack-key-name'
      all_my_flavors: [ 1, 2, 3, 4 ]

  extra_blueprint:
    description: Some additional blueprint
    type: blueprint_id

  lenghty_description:
    description: A large field for notes
    type: textarea
    display:
      rows: 20

  deployment_ids:
    description: A list of deployment IDs starting with dep
    type: list
    item_type: deployment_id
    constraints:
      - name_pattern:
          starts_with: dep

node_templates:

  vm:
    type: cloudify.openstack.nodes.Server
    properties:
      server:
        image_name: { get_input: image_name }
        key_name: { get_input: [ extra_vm_details, key_name ] }
        flavor: { get_input: [ extra_vm_details, all_my_flavors, 0 ] }

get_input is a special function which enables you to use inputs throughout the blueprint. For more information see intrinsic_functions.

Another example, with data_types

inputs:
  ports_conf:
    type: port_conf
data_types:
  port_conf:
    properties:
      webserver_port1:
        type: integer
      webserver_port2:
        type: integer

The ports_conf input that will be provided must comply with the port_conf data_type schema. Meaning that it must have two properties, webserver_port1 and webserver_port2, and both of them must be integers.

Constraints

Constraint dict format

Each constraint must be in the following format:

{ constraint_operator: argument_or_argument_list }

List of Constraint Operators

name_pattern details

The name_pattern constraint applies to various data types. There are different fields (attributes) being compared to. In the following table we have included information on the specifics of these fields.

Following criteria might be used to declare name_pattern (all accept strings as their parameters):

deployment_id details

The deployment_id is a required constraint for capability_value, scaling_group, node_id, node_type and node_instance data types.

Constraints examples

In the following example, the image_name input must comply with the given regex, otherwise an error is displayed.

inputs:
  image_name:
    description: The image name of the server
    type: string
    default: "Ubuntu 12.04"
    constraints:
      - pattern: "Ubuntu \\d{2}\\.04"

    constraints:
      - pattern: |-
          Ubuntu \d{2}\.04

In the next example, the additional_blueprint input must an identifier of a blueprint, which exists in the system and is visible to the tenant/user in the operation’s context. On top of that, a blueprint must be owned either by default_tanant or other_tenant and meet requirements of shared-blueprints blueprint filter. If any of these criteria is not met, an error is displayed.

inputs:
  additional_blueprint:
    description: An additional blueprint
    type: blueprint_id
    constraints:
      - filter_id: shared-blueprints
      - tenants:
          - default_tenant
          - other_tenant

The following example shows the master_deployment input, which must be a valid identifier of a deployment (visible to the tenant/user). On top of that, a deployment’s (display) name must contain string shared and it should have these two labels set: csys-obj-type=service and obj-type=k8s.

inputs:
  master_deployment:
    description: A master deployment
    type: deployment_id
    constraints:
      - labels:
          - csys-obj-type: service
          - obj-type: k8s
      - name_pattern:
          contains: shared

In the example below, my_app_port is an input which must match the value of port capability of of app01 deployment. Keep in mind, that deployment_id is a required constraint for the capability_value data type.

inputs:
  my_app_port:
    description: A port my application listens on
    type: capability_value
    constraints:
      - name_pattern:
          equals_to: port
      - deployment_id: app01

The next example contains a few other inputs of data-based types:

• my_token is an input which will match any key of a secret present in the system, which ends with “token”,
• app_scaling_group will match the names of app deployment’s scaling groups,
• app_node_id_a_z will match any identifier of the node present in the app deployment, which start with “a” and end with “z”,
• app_node_type will match any type of the node present in the app deployment, which contains a string “Compute”.

inputs:
  my_token:
    type: secret_key
    constraints:
      - name_pattern:
          ends_with: token
  app_scaling_group:
    type: scaling_group
    constraints:
      - deployment_id: app
  app_node_id_a_z:
    type: node_id
    constraints:
      - name_pattern:
          starts_with: a
          ends_with: z
      - deployment_id: app
  app_node_type:
    type: node_type
    constraints:
      - name_pattern:
          contains: Compute
      - deployment_id: app