As a cloud administrator you create projects, add users as project administrators or members, and assign cloud zones that provide the infrastructure resources to support the member goals. Anyone who creates and deploys blueprints must be a member of at least one project.

What is the best way to set up projects

Blueprint developers need resources that support their development goals. As the cloud administrator, you compare the development requirements to your cloud zones, and then add the necessary zones to a project. Users can be members of more than one project.

Project considerations for cloud administrators.

  1. Do you understand the business needs of your development team? Do you have the cloud vendor resources to support those needs?

  2. Have you created cloud zones based on the cloud vendor accounts that contain the resources your development team needs? To understand how projects work, see How do Cloud Assembly projects work at deployment time.

  3. Did you map flavors and images and for the account regions in those zones? The mappings provide common names for machine sizes and operating systems across zones. The common names are then used in the blueprints. See flavors and images.

  4. Have you configured the network and storage profiles for the account regions in your zones? See network and storage.

  5. Should you use the project constraints to control placement or rely on the blueprint constraints? See the following section.

  6. Do you want to use the project custom properties to facilitate external reporting or to trigger or populate extensibility actions or workflows? See a following section.

If you have addressed all the considerations, select Infrastructure > Projects and click New Project. Create a project that includes the cloud zones and the blueprint developers who you want to deploy blueprints to those zones.

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 capability 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.

	- tag: 'loc:mumbai'
failOnConstraintMergeConflict: true

How might I use project custom properties

A project custom property can be used 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 Learn more about extending and automating 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.

How are my blueprints associated with for a project

When you create a blueprint, you first select the project to which it is associated. The project must exist before you create the blueprint.

The project does two things.

  • Determines which users can see the blueprint in the Blueprints tab. Project members can see and deploy project blueprints.

  • Determines where the blueprint components are deployed based on the blueprint and project constraints that are defined for the project cloud zones.

To create a blueprint, click the Blueprints tab and click New.