As an administrator, you can add project-level governance constraints or custom properties when the requirements of the project are different from the vRealize Automation Cloud Assembly blueprints. 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, 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 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.
failOnConstraintMergeConflice:truein the blueprint. For example, you project has a network
loc:londonconstraint, 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 life cycles 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.