This solution at a glance:
- Deleting a project makes resources within that project unusable.
- The best solution for “orphaned” resources is to delete and recreate them.
- If you need to delete a project, delete any resources it contains first.
- Understanding Dependencies Between Resources in Your Cloud
- Understanding How Deleting a Project Affects Cloud Resources
- Deleting “Orphaned” Resources
If networks, routers, or instances become unusable or "invisible" to Metacloud users in your Availabiity Zone (AZ), a Metacloud administrator should determine if these resources are still included within a project. If they were previously part of a project, but the project was deleted, the resources are "orphaned" and inaccessible.
To find "orphaned" resources, click the Admin drop-down list and view pages for networks, routers, and instances. "Orphaned" resources do not have a project associated with them:
Understanding Dependencies Between Resources in Your Cloud
The deployment of resources in your Metacloud cloud occurs in a sequence because of how these resources depend upon each other. Being aware of these dependencies helps you understand the impact of deleting a project.
Alternately known as a tenant, a project is a logical, isolated subdivision of your AZ, with an 802.1Q virtual LAN (VLAN) and a unique address space.
Non-admin Metacloud users only see resources in their designated project and do not have access to resources in other projects unless Metacloud administrators provide it. Metacloud administrators can access resources in all projects within an AZ.
At least one project must be created for your cloud before you can create a network.
Every Metacloud internal network exists within the context of at least one project. Networks can also be shared between all projects in an AZ.
Note: Sharing networks between projects is not considered a best practice. It provides some conveniences, such as as facilitating communication between projects without the need for floating IPs, but it presents security challenges. As of Metacloud 4.0 (Liberty/Fusion), it is not possible to select specific projects to share networks, which means that all resources in a shared network are exposed across the entire AZ.
After creating an internal network, you can later create a router to connect it to other internal networks and to an external network.
Subnets and Ports
You must create a subnet for a network before you can connect any instances to that network.
When you create a subnet, the Metacloud network service (neutron) automatically creates a DHCP service and a port for that subnet.
Routers and Ports
After creating internal networks and subnets within a project, you must create a virtual router if you want to connect the networks and provide them with a default gateway to an external network.
When you create a router, the Metacloud network service automatically creates a port for that router.
Instances and Ports
Once you create a subnet, you can connect instances to the network.
When you create an instance, the Metacloud network service automatically creates a port for that instance.
Understanding How Deleting a Project Affects Cloud Resources
Because of these dependencies, if a Metacloud administrator deletes a project, the networks, subnets, routers, and instances contained in it become unusable. Users are unable to connect new VMs to “orphaned” networks unless those networks are being shared between multiple projects.
For example, an AZ contains three projects created by a Metacloud administrator: Tenant A, Tenant B, and Tenant C. The administrator deletes Tenant B, which contains one shared network, named Green, and a non-shared network, named Red.
The administrative view of networks in the Dashboard shows the Green and Red networks as being “orphaned” or not belonging to a project:
Users in the Tenant A and Tenant C projects are not able to connect new instances to Red, which is not a shared network. They can, however, connect new instances to Green, which is a shared network:
Deleting “Orphaned” Resources
"Orphaned" and unusable networks, subnets, instances, and routers take up disk space and resources. The best solution is to delete and recreate them. You must be a Metacloud administrator to perform this action because administrators can view all resources within an AZ, including those that don't belong to projects.
Since resources are created in a specific order because of their dependencies (network, subnet, instances and router), you should delete them in the opposite order:
Then recreate them in order of dependency in a different project:
Using the Dashboard to Delete "Orphaned" Resources
If you are operating Metacloud 4.0 (Liberty/Fusion) version or later, use the Dashboard, which is more convenient for this action because it provides a visual context, making orphaned resources easer to locate.
- Make sure to note any attributes for resources that you want to recreate after deletion, such as IP ranges for subnets.
- Log into the Dashboard and click the Admin drop-down list.
- Create snapshots of any instances that you want to recreate after deletion: On the Admin > Instances page, select the drop-down option to create a snapshot for each orphaned instance that you want to recreate later.
- Make the snapshot images public so that you can use them in other projects: On the Admin > Images page, choose Edit Image from the drop-down for each snapshot you created and select the Public checkbox on the Update Image page.
- Delete "orphaned" instances: On the Admin > Instances page, select the drop-down option to terminate each instance that was in the deleted project.
TIP: To delete multiple instances, sort the instances in the table by Project, select the check boxes with no projects, and click TERMINATE INSTANCES above the table.
- Delete "orphaned" routers: On the Admin > Routers page, delete the router that was in the deleted project.
Tip: If you get an error when attempting to delete a resource, try deleting its associated port first.
- Delete subnets of "orphaned" networks: On the Admin > Networks page, click the hyperlink for the "orphaned" network. Then select DELETE SUBNET from the drop-down list for each subnet on the NETWORK OVERVIEW page.
- Delete the "orphaned" network: On the Admin > Networks page, select the drop-down option to delete the network.
Using the Command Line Interface (CLI) to Delete "Orphaned" Resources
If you are using an earlier version of Metacloud than 4.0, you need to use the CLI to delete and recreate "orphaned" resources. You can still use the Dashboard to view and record information about the resources and to snapshot instances that you want to recreate later.
Note: For all of the following commands, you need the UUIDs of "orphaned" resources that you want to delete. You can view these IDs in the Dashboard on the OVERVIEW pages for the resources.
Delete an "orphaned" instance:
$ openstack server delete <INSTANCE_UUID>
Delete an "orphaned" router:
$ openstack router delete <ROUTER_UUID>
Delete an "orphaned" subnet:
$ openstack subnet delete <SUBNET_UUID>
Delete an "orphaned" network:
$ openstack network delete <NETWORK_-UUID>
If you get an error when attempting to delete a resource, try deleting its associated port first.
On the to Admin > Networks page, click the hyperlink for the "orphaned" network and delete the port on the NETWORK OVERVIEW page. Typically, ports are automatically deleted along with the services to which they are attached.
If your attempt to delete a port generates an error, detach it from its "owner," which is the service using the port. In the following example, the owner is a router:
- On the to Admin > Networks page, click the hyperlink for the "orphaned" network.
- On the NETWORK OVERVIEW page, click the hyperlink for port that you are unable to delete.
- On the Port Overview page, note the UUID of the port and the name of the device owner. You will need this information in the following step.
- In the CLI, detach the port from its "owner":
$ neutron port-update <PORT_UUID> --device_owner compute:None
- Delete the port, either in the Dashboard or run:
$ neutron port-delete <PORT_UUID>
$ openstack port delete <PORT_UUID>
Best Practice for Deleting Projects
Various situations may warrant deleting a project, such as the following:
- You may want to change how your cloud tenants are arranged in order to align with organizational changes in your company.
- You may want to consolidate or redistribute resources.
- A temporary project may have been created for internal use and is no longer necessary.
If you need to delete a project, make sure to delete all resources contained within the project first.