vRealize Automation 8.x - Delete Resource From Deployment

If you have ever tried to create a deployment, succeeded, and then found out that it didn’t actually deploy a VM but thinks it did and now fails to delete the deployment because it cannot delete the thing it didn’t create (…yes, this happens…sadly) let me save you a LOT of heartache with support.

The first thing you will need to do is SSH into the primary vRA instance in the cluster as root.

Once you are there are going to need to get inside the kubernetes pod hosting the postgres DB and manually delete entries.

Now would be a good time to tell you that VMWare DOES NOT SUPPORT YOU MANUALLY EDITING THE DATABASE IN THIS OR ANY OTHER WAY AND YOU SHOULD NOT DO ANY OF WHAT I AM EXPLAINING.

The safe bet? Make them fix it. That is going to take winding your way through some painful conversations and a fair amount of “try this API call” that is probably malformed, before they finally escalate to engineering to do…what I’m showing you how to do here.

But at least if they screw it up they get fired and not you. :)

Annnnyway, back to making some bad decisions eh?

Ok, so if you are doing this kubectl should NOT be something you are learning about for the first time. If it is…please call support…or do this in a lab…

kubectl -n prelude get pods

You want the little guy that says “postgres-0”, in fact you can skip the previous step and just know it is going to be named postgres-0…I’m just putting this here so if it changes in the future you know where to find it. I would recommend doing this FROM the primary VRA node TO the primary postgres pod…why tempt fate.

Next we need to exec a bash command into the pod:

kubectl exec -n prelude -it postgres-0 — /bin/bash

Now we need to elevate:

su postgres

Now we are going to use the postgres command line client to find and trash our misbehaving entries.

psql catalog-db

Note if it doesn’t dump you into that DB you can list the DB’s with \l and then change to that db with \c catalog-db

Now to find out problem children. If you are doing this IN A LAB LIKE A SMART PERSON…ahem…you likely don’t have many entries…you can just:

SELECT * FROM dep_resource;

Now, depending on your screen size and number of entries you may want to use \x before this command, it can make it easier to read just remember you will need to \x again when you are done before you will be able to exit the DB with \q…I don’t know why that is a thing, but it is…

Find the name of the resource you want to delete and run the following command IN A LAB.

DELETE FROM dep_resource WHERE name ~ ‘unique part of the resource name here’

OR if you named them all very similarly don’t use “like”, be specific.

DELETE FROM dep_resource WHERE name = ‘full name of resource here’

Once done exit the db with \q (don’t forget \x before if you turned on expanded display) and go check cloud assembly, you should see it no longer lists the resources in question, you should now be able to delete the deployment.

Here are some things you can spend the time you saved on a call with support doing:

• Wondering why the “ignore delete errors” button doesn’t actually ignore these errors.

• Wondering why it would let you create VM’s with invalid names in the first place.

• Wondering why it thinks it deployed a resource it did not, in fact, deploy…

• Drinking to forget the pain…

Or you could spend that time moving on to the next broken thin in vRA 8.x

Hello, World!