If you need to delete custom adapter kinds and custom resource kinds from vROPs 6.6.x, VMware support can create a .pak file tailored to your resource kind names. By installing the .pak file as a solution to vROPs, and then uninstalling it, it will remove the custom adapter kinds entirely.
There is no way to do this thru the GUI or API. I’d like to see VMware add a REST DELETE method to support this in a future release of the product.
Context – Adding Custom Metrics in vRealize Operations
Let’s say you want to use vRealize Operations Manager to track metrics for some kind of resource that isn’t already available in the solution adapter ecosystem. For example, performance and capacity information for Cloudian Hyperstore such as S3 operations per second and bytes used by group.
What happens when you add custom metrics via the REST API?
When you push custom metrics, you define a new adapter kind and resource kind(s). vRealize Operations Manager creates a new adapter of type “OPENAPI” to track your objects. They look like this in the Environment tree:
Unfortunately, it is not possible through the REST API nor the web user interface to DELETE these adapter kinds and resource kinds after they have been created. You can delete the instances of the adapters and resources, but not remove the kind from the schema.
Why do we need to remove custom adapter kinds anyway?
This can be a problem for several reasons. For example, when developing against vROPs, certain characteristics of resources are defined the first time the resource is created and cannot be modified later.
In particular, using custom resourceIdentifiers, used to identify objects by a set of IDs beyond simple object name matching, the custom resource identifier fields must be defined the first time the resource is created, in my experience anyway.
From the Administration -> Inventory view, here’s an example of custom resource identifiers, all 4 items listed under “Basic Settings” in the screenshot:
The only way to modify the schema here, as far as I am aware, is to entirely remove the resource kind and recreate it ensuring all desired custom resource identifier fields are defined on the first push to vROPs.
Hope this helps.