You can add project-level governance constraints or custom properties when the requirements of the project are different from the Cloud Assembly blueprints.

What are project constraints

A project constraint operates as a governance definition. It is a key:value tag that defines what resources the deployment request consumes or avoids in the project cloud zones.

The deployment process looks for tags for the networks and storage that match the project constraints, and deploys based on matching tags.

The extensibility constraint is used to specify which vRealize Orchestrator integrated instance to use for extensibility workflows.

Consider the following formats when you configure project constraints.

  • key:value and key:value:hard. Use this tag, in either format, when the blueprint must be provisioned on resources with the matching capability tag. The deployment process fails when no matching tag is found. For example, a blueprint deployed by the members of a project must be provisioned on a PCI-compliant network. You use security:pci. If no networks are found in the project cloud zones, the deployment fails, ensuring no insecure deployments.
  • key:value:soft. Use this tag when you prefer a matching resource, but you want the deployment process to proceed without failing and can accept resources where the tag does not match. For example, you prefer that the project members deploy their blueprints to a less expensive storage, but you do not want storage availability to interfere with their ability to deploy. You use tier:silver:soft. If there is no storage tagged tier:silver in the project cloud zones, the blueprint still deploys on other storage resources.
  • !key:value. Use this tag, with hard or soft, when you want to avoid deploying to resources with a matching tag.
Importantly, the project constraint tags have a higher priority than the blueprint constraint tags and override them at deployment time. If you have a blueprint where this must never happen, you can us the failOnConstraintMergeConflice:true in the blueprint. For example, you project has a network loc:london constraint, but the blueprint is loc:mumbai, but rather than the project location taking precedence, you want the deployment to fail with a constraint conflict message. You add the property similar to the following example.
constraints:
	- tag: 'loc:mumbai'
failOnConstraintMergeConflict:true

How might I use project custom properties

You can use a project custom property for reporting, to trigger and populate extensibility actions and workflow, and to override blueprint level properties.

Adding a custom property to a deployment allows you to use the value in the user interface or to retrieve it using the API so that you can generate reports.

Extensibility can also use a custom property for an extensibility subscription. For more information about extensibility, see How to extend and automate application lifecycles with extensibility.

A blueprint might have a particular property value that you want to change for a project. You can provide an alternative name and value as a custom property.