As an administrator, you can add project-level governance constraints or custom properties when the requirements of the project are different from the Cloud Assembly cloud templates. In addition to constraint tags, you can add resource tags that are added to deployed resources during the provisioning process so that you can manage the resources.

What are project resource tags

A project resource tag operates as an standardized identifying tag that you can use to manage the deployed resources and ensure compliance.

The resource tags defined in a project are added to all component resources deployed as part of that project. You can then use the standard tagging to manage the resources using other applications, for example, monitor spending cost using CloudHealth, and, importantly, to ensure compliance.

For example, as a cloud administrator, you want to use an application like CloudHealth to manage costs. You add the costCenter:eu-cc-1234 tag to a project dedicated to developing a European Union human resources tool. When the project team deploys from this project, the tag is added to the deployed resources. You then configure the costing tool to identify and manage the resources that include this tag. Other projects with other cost centers would have alternative values to go with the key.

What are project constraint tags

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 cloud template must be provisioned on resources with the matching capability tag. The deployment process fails when no matching tag is found. For example, a cloud template 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 cloud templates 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 cloud template 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 cloud template constraint tags and override them at deployment time. If you have a cloud template where this must never happen, you can use the failOnConstraintMergeConflict:true in the template. For example, if your project has a network loc:london constraint, but the cloud template is loc:mumbai, but rather than the project location taking precedence, you want the deployment to fail with a constraint conflict message, you add a property similar to the following sample. 
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 cloud template 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 Extending and automating application life cycles with extensibility.

A cloud template 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.

You can also encrypt the property value so that neither you nor your users can see the value that is included in the deployment. For example, you can encrypt a password that all users in the project use, but that you do not want visible. After you encrypt the value and save the project, you cannot unmask or replace the value. If you clear the Encrypted check box, the value is removed. You must re-enter a value.