The deployment criteria narrows the scope of a policy so that it is applied only to the deployments where the criteria is true. For example, you can use the deployment criteria to create a policy that is applied only to a particular catalog item or template.

Constructing deployment criteria

You use the graphical interface to construct the deployment criteria expression. To construct complex expressions, you can use AND and OR. You can also group expressions as parenthetical operators. For more about how the expressions are processed, see Order of operations for the expression.

Here is an example of an expression.
Deployment equals Multi-tier five machine with LB AND (Owned By equals [email protected] OR Owned By [email protected])
Using the deployment criteria components, it looks like the following example.
Example of the deployment criteria.

Deployment criteria properties

To create a functional deployment criteria, you must understand the syntax.

The criteria text box has various drop-down menus that provide the available properties and operators. How you construct your expression depends on the available values and on the order of operations.

The drop-down menus include the following properties. Some properties vary between policy types.

Property Description Available in these policy types Supports these operators
Cloud Template

Identifier for the Cloud Assembly cloud template that was used to create the deployment.

Use Cloud Template rather than Catalog Item when your policy is specific to Cloud Assembly cloud templates. For example, an Amazon Web Services template does not have a Cloud Template.

  • Approvals
  • Day 2
  • Lease
  • equals
  • not equal to

Catalog Item

Identifier for the Service Broker catalog item that was used to request the deployment.

Use Catalog Item rather than Cloud Template when your policy can include Service Broker catalog items based on any template, extensibility workflow, or other content type. For example, Cloud Assembly cloud templates and Amazon Web Services CloudFormation templates deployed from the catalog have a Catalog Item.

  • Approvals
  • Day 2
  • Lease
  • equals
  • not equal to
Deployment Creation Cost

Cost value.

If the deployment matches the specified cost expression, it triggers an approval flow.

  • Approvals
  • equals
  • not equal to
  • greater than
  • greater than or equal
  • less than
  • less than or equal
Deployment

Identifier for the deployment.

Use Deployment when you want to apply the policy to existing deployments.

  • Approvals
  • Day 2
  • Lease
  • equals
  • not equal to
Created By

Name of the user who requested the deployment. The format is [email protected].

This user is the user who requested the deployment.

  • Day 2
  • Lease
  • equals
  • not equal to
  • matches Regex
  • contains
Name

Deployment name.

Use Name rather than Deployment when you want to apply the policy to existing policies and policies that can be created in the future that match the specified deployment name expression.

  • Approvals
  • Day 2
  • Lease
  • equals
  • not equal to
  • matches Regex
  • contains
Owned By

Name of the current deployment owner.

  • Approvals
  • Day 2
  • Lease
  • equals
  • not equal to
  • matches Regex
  • contains
Requested By

Name of the user who requested a day 2 action. The format is [email protected].

When creating approval policies, the Requested By criteria is the user who requested a day 2 action, not the user who requested the deployment. The user who requested the deployment is the Created By criteria.

  • Approvals
  • equals
  • not equal to
  • matches Regex
  • contains
Resources

Resources that are part of a deployment.

You can define the deployment criteria based on the following resources.

  • Cloud Zone
  • Cloud Account
  • CPU Count
  • Cloud Type
  • Disks
  • Flavor
  • Has Snapshots
  • Image
  • Image ID
  • OS Type
  • Power State
  • Region
  • Tags

    User-defined and discovered tags.

  • Total Memory (MB)
  • Resource Type
  • Approvals
  • Day 2
  • Lease

Criteria formats for resource tags

Resource tags are key value pairs. When you define deployment criteria based on the tags, you must define the key. Defining the value is optional. The criteria are based on user-defined tags and system tags.

For example, to create criteria for one tag pair, the expression is similar to the following example.
Resources has any 
    Tags has any 
        Key equals env 
        AND 
        Value equals dev
Example of the simple deployment criteria expression of one key value pair as it appears in the UI.
To create criteria based on one key but multiple values, the expression is similar to the following example.
Resources has any 
    Tags has any 
        Key equals env 
            AND 
                Value equals dev 
                OR
                Value equals prod
Example of the single key and multiple value deployment criteria expression as it appears in the UI.
To create criteria based on multiple keys but no values, the expression is similar to the following example.
Resources has any 
    Tags has any 
        Key equals env1 
        OR 
        Key equals env2
Example of the multiple keys deployment criteria expression as it appears in the UI.
If you want to create criteria that evaluate two different key value pairs, then you must add them as individual resource tags. For example,
Resources has any 
    Tags has any 
        Key equals env 
        AND 
        Value equals envprod
    AND
    Tags has any 
        Key equals vc_65_network 
        AND 
        Value equals vc
Example of the multiple key and value deployment criteria expression as it appears in the UI.

Using the contains and matches Regex operators

The contains and matches Regex operators define a search for a specified set of characters within a property. You can apply these operators to string based properties that do not support a drop-down, such as createdBy, name, and ownedBy.

The contains operator searches for all instances of the value you specify in any context. The value input text box is case sensitive and space sensitive. If you want to account for context variation, you must set a value for each additional variant. Use the contains operator for simple searches for a limited number of values.

The matches Regex operator provides great flexibility when you use it for complex searches that must account for a lot of context variation. The regular expressions must follow ECMAScript syntax. When defining regular expressions, do not enter the forward slashes (/) at the beginning and at the end of the value.

The following table provides examples of expressions using the two operators and compares how they might be used to achieve the same goal.

Example with the contains operator Example with the matches Regex operator Field value matches
Name contains test
Name matches Regex test*

All deployment names that contain test in lowercase. For example, test deployment, mytest, test-123, and so on.

Name contains test
OR
Name contains Test
Name matches Regex (t|T)est.*

All deployment names that contain test or Test.

(group)
	Created By contains admin@
	(group)
	AND
		Created By contains .com
		OR
		Created By contains .org
(group)
AND
	Name contains test
	OR
	Name contains test-
	OR
	Name contains Test
	OR
	Name contains Test-
	OR
	Name contains deploy
	OR
	Name contains Deploy
Created By matches Regex admin@\S+\.((com)|(org))
AND
Name matches ((t|T)est)|(d|D)epl.*.

All deployments that are created by users whose email address starts with admin@ and ends with .com or .org.

All deployment names that contain test and/or deploy in any configuration. For example, test deployment, testdeployment, Test-Deployment, and so on.

Order of operations for the expression

An expression is processed in the following order. Groups are illustrated as parentheses.

  1. Expressions in groups
  2. AND
  3. OR

Use the following examples to understand the order.

  • X OR Y AND Z. In this example, Y AND Z is evaluated before X OR Y. Next, the X OR is evaluated against the results of Y AND Z.
  • (X OR Y) AND Z. In this example, X OR Y is evaluated before AND because the expression in the group is always evaluated first. Next the AND Z is evaluated against the results of X OR Y.