Being a customer-centric company, with each new feature our focus is to fully meet the business needs of our clients. During the recent VMware Aria Automation releases we have introduced a highly requested functionality – “Change Project.” It allows the Cloud Administrators to easily move their resources across projects.
What are projects?
If you have used VMware Aria Automation, and specifically VMware Aria Automation Assembler, you have most certainly used projects. Our clients use them for grouping users (each with a specific role), cloud templates, and deployments to reflect their large organizational structures, which are often subject to change. This is where the “Change Project” functionality comes into place.
What is the “Change Project” feature?
Change Project is a Day 2 action which transfers deployments from one project to another. Executed at the deployment level, it gives customers flexibility with changes in their organization.
How Change Project works?
Let us dive into what Change Project does under the hood. The action does more than assigning a deployment to another project. If we take a step back to see what is inside a deployment, we can outline a few key components – cloud zone, resources, any applicable policies (or project restrictions). Each resource in the deployment, contained in a project, must have a cloud zone where it is being deployed. This is defined in the cloud template from which the deployment is provisioned.
If we want to move this deployment to another project, there are certain prerequisites that need to be considered. Otherwise, the Change Project Day 2 action will not succeed, and the users will see a specific message to take corrective measures.
Privileges
Only users with the VMware Aria Automation Assembler Administrator role can run the Change Project action. The existing owner of the original project should also be owner of the target project, or be part of a group added in the new project. All resources in the deployment, that is being moved, must exist and still be part of it – the action will not be available if there are any resources with status “stale” or “missing”. You must also ensure that the target project has the same cloud zone as the source project.
Quota
When running Change Project action, quotas are released from the cloud zone of the source project and the same quotas are reserved in the target project. Validation is needed to ensure the destination project quota limits can handle the source project’s resources.
Lease policies
After successful Change Project execution, the target project’s lease policies are applied to the deployment. They might cause it to expire immediately. To prevent this, we validate that the deployment won’t expire in the target project in the next 24 hours. You can read more about how lease policies work in the following blog post.
Change project for “hybrid” deployments
Historically, deployments and resources of different origins have often been mixed, such as inbuilt resources, custom resources developed through extensibility, Terraform/Ansible and others. A single deployment can contain both onboarded and deployed resources, onboarded and migrated resources, or any other such combination. That opened the door for use cases where the “Change Project” is required.
In such cases, the final stage of validation that we would perform is checking whether the deployment is a so-called hybrid deployment. Apart from the previously mentioned verifications, we would have to make sure to include those types of deployments in the validation workflow as well, so that clients can have the best experience in all their scenarios and use cases.
After the validations are completed, the actual change of project is a 3-step process, executed for each resource in the deployment. First, the quota in the target project is reserved. Second, the resource is associated with the new project. Finally, the quota from the target project is released.
Being focused on bringing immediate customer value and collecting iterative feedback, the “Change Project” feature was released in several phases and as of the April release, it is supported for deployments containing resources with the following origins:
- Provisioned (machines, disks, load balancers, networks, security groups, Azure groups, NATs, gateways, custom resources, Terraform configurations, and Ansible resources)
- Onboarded (machines, disks, and networks)
- Migrated (machines, disks, load balancers, networks, security groups, NATs, gateways, and custom resources)
Summary
VMware is excited to offer the Change Project feature in VMware Aria Automation. We always strive to create value for our clients, to increase customer adoption and consumption and form long-term partnerships. For more product-specific feature details you can check out the official documentation.
