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!
App-V: Firefox 8
Was about to put up a whole guide on FF8 when I saw Aaron Parker put a guide up of his own. No point in re-inventing the wheel so I'll just point over in that direction.
Hasn't really changed much since the FF5 stuff I posted on the official forum and what was already out at the time, so it's largely mroe of the same.
One thing I did want to mention though which applies in general to more than just Firefox is how to handle swapping out applications like this.
For a few reasons I wont get into I decided to sequence this as a new app and not an upgrade to version 5. This causes an interesting issue. How do I remove version 5? If I just strip the permissions and delete it then anyone who tried to launch it between now and their next reboot will effectively not have Firefox.
What you want to do is slowly get rid of it. The best way I have found is to add Firefox 8 to the AVS, then goto the Firefox 5 Application Group and disable the shortcuts.
What this will do is LEAVE Firefox 5 working and intact for everyone who has it, but when they next reboot or log off/on the shortcuts will go away and the shortcut for 8 (which appears to have moved to the root of Programs btw) will come down.
After a span of time that seems to provide a reasonable likelihood that everyone who uses 5 has rebooted or relogged (3 months, 6 months, depends on the size and type of your company, if it's small enough maybe a month, if you force a reboot via something like SCCM, you can control it, but I'm trying to do this as "in the background" as possible) you can remove Firefox 5 from AVS all together.