VMware Cloud Community
croeleveld
Contributor
Contributor

Possible bug: getCatalogResourceActions returns array with identical elements

This week I tried execute actions on vCAC items from vCO and ran into a possible bug in the plugin. I am using the the vCAC6.01 plugin version.

In this particular case I was trying to reboot a physical machine deployed by vCAC. In vCAC you can do this in "Items" -> item dropdown -> restart. I was trying to build this into the workflow that is called at the MachineProvisioned state change.

Luckily there is the "Request a resource action" workflow which comes with the plugin. That should do the job. Right?

wrong: It doesn't matter which action I select for the resource, it always tries to execute the first action listed. So for my physical machine it always requests "change lease" and for a virtual machine it always request "Open VMRC console".

The workflow itself looks fine and so do the actions used. So I dug a little deeper and used the "getAvailableResourceActions" action to see what it returns. Well, it returns an array which has as many elements as there are actions on the object but every element contains the same object.

I checked what is returned if I run vCACCAFEEntitiesFinder.getCatalogResourceActions in a scriptable action and the result is the same. See attached screenshot for proof.

tl;dr: The vCACCAFEEntitiesFinder.getCatalogResourceActions returns an array in which every element is identical so you can't actually use the resource actions from vCO.

Seems like a bug to me or am I missing something?

10 Replies
akracheva
VMware Employee
VMware Employee

Yes, it's a bug in the vCAC6.0.1 plug-in version. It is fixed in vCAC6.0.1u1 plug-in version which is generally available for download.

https://my.vmware.com/group/vmware/get-download?downloadGroup=VCO_VCAC_PLUGIN_6011

Thanks,

Asya

Reply
0 Kudos
croeleveld
Contributor
Contributor

thanks for the answer. I double checked and indeed this customer is running the older version. Good to know it's fixed in the newer relase.

Reply
0 Kudos
SeanKohler
Expert
Expert

Seems to be broken in a different way now in 6.1?

The items are Resource Actions (RA), and the ConsumerResourceOperation type is bad/unused? Is it going to be actually fixed in 6.2?  Sure hope so...

Reply
0 Kudos
gmuleshkov
VMware Employee
VMware Employee

I checked the screenshot and I suppose that are are not able to add elements because of the type. It is a little bit confusing but if you want to add elements from the inventory that are under the folder "Resource Operation" the type should be CatalogResourceAction. If you change the type when you select an item the "Add" button will be enabled.

CatalogResourceAction.png

ConsumerResource operation is the type of the items shown as children of the "Items" in the inventory. I attach a screenshot.

ConsumerResourceOperation.png

I hope this helps.

Best Regards,

Georgi

Reply
0 Kudos
SeanKohler
Expert
Expert

Thank you for the help, Georgi.

I understand the type definitions, and I don't want to hijack the original intention of this thread... but I will a little bit...

One of the points I think I am trying to make is that vCACCAFEEntitiesFinder.getCatalogResourceActions(vCACCAFECatalogResource) returns vCACCAFEConsumerResourceOperation when there actually is a data type called CatalogResourceAction as shown in your first screenshot.  So it is actually NOT getting CatalogResourceActions as the method implies by the name.

Secondary to this information, and the reason why I am interested in this topic, is that I have been unable to figure out how to run an entitled CatalogResourceAction against an item though any other means than the VCAC CLI with a REST call.  Even the same REST call through VCO using host.createRestClient(vCACCAFEServicesEnum.CATALOG_SERVICE) and then a POST fails with a 403 forbidden error.

If you or anybody has a method to reboot a machine, change a lease, etc... leveraging the CatalogResourceActions, I would be ecstatic.  (e.g. I know I could to a machine reboot through VC plugin... but the intention is to leverage VCACCafe:CatalogResourceAction)

Reply
0 Kudos
croeleveld
Contributor
Contributor

well... the data types seem to be all over the place in the CAFE plugin. If you lookup the CatalogResourceAction data type you'll see that it maps to the ResourceAction scripting object....

That's not the only weirdness in the plugin. Look at the adminCatalogItem type. the getAdminCatalogItem() method returns a CatalogItem type. Not an AdminCatalog Item. If you use an AdminCatalogItem as an input for a workflow nothing seems to actually work. vCO tells me I'am accessing "Object not found" while I just selected it in the object browser.....

but enough complaining about the plugin. If you want to do resource actions on resources here is what should work:

You can find the resource operation you're looking for with this bit of code:

-----

//resource = vCACCAFE:CatalogResource type

//actionName = string with action name. ie: "Edit".

var allOperations = resource.getOperations();

var opIndex = allOperations.map(function(o) { return o.name.toUpperCase() }).indexOf(actionName.toUpperCase());

var resourceAction = allOperations[opIndex]; //vCACAFEConsumerResourceOperation type

//if above fails, add this:

var action = vCACCAFEEntitiesFinder.getCatalogResourceAction(resource, resourceAction.id);

--------

You can execute the action you found by using the requestResourceAction action. Which takes the ConsumerResourceOperation as an input together with the inputs for the action as a properties object. And that's where it gets tricky. I have an example here which I used to change the owner of a resource. The inputs properties object looks somewhat like this:

-----

var FormInputs = new Properties();

FormInputs.put("provider-operationId", vCacConsumerResourceOperation.getBindingId());

FormInputs.put("provider-machineId", resource.getProviderBinding().getBindingId());

FormInputs.put("provider-TARGET_MACHINE_NAME", resource.name);

FormInputs.put("provider-Cafe.Shim.VirtualMachine.Owner", <new user id>);

-----

I hope this helps a bit.

SeanKohler
Expert
Expert

Thanks.  Working through the details...

Reply
0 Kudos
SeanKohler
Expert
Expert

So I finally had a moment to look through this.  Thank you again for putting something out there to look into.

It appears I am running into the same wall with the script you shared, unfortunately.

No Ops.jpg

Reply
0 Kudos
rszymczak
Hot Shot
Hot Shot

Hi Sean,

I'll just copy & paste the answer I allready provided here trying to spread the information in as many related threads as possible so if anyone comes around here he/she might find the information.

there seems to be a bug with the vCAC Plugin for vRO anyways. Tested this with the vCACCAFE plugin version 6.2.1 and vCAC plugin version 6.2.1.

I'm using a shared session for both plugins and the plugin user has sufficient permissions. Also I'm able to see the actions listed for each item when browsing the plugin inventory.

The results I found don't make sense (yet) but seem to indicate a bug.

// This works if the vCACCAFE:CatalogResource is provided as workflow input parameter

var ops = item.getOperations(); // will return a Array containing all operations

for each (op in ops)

{

  System.log("Action: " + op.name);  // works

}

// But it fails, if the vCACCAFE:CatalogResource is dynamically collected using EntityFinder or other methods

bindingId = iaasVM.virtualMachineID;

cafeItems = vCACCAFEEntitiesFinder.getCatalogResources(cafeHost);

for each(item in cafeItems)

{

  if(item.getProviderBinding().getBindingId() == bindingId)

  {

       // The correct item is found and of type vCACCAFE:CatalogResource

       var operations = item.getOperations(); // however, this will ALWAYS return an empty Array!

  }

}

As you can see the plugin user seems to have sufficient permissions, because when calling item.getOperations() the array of operations is returned (first case). In the second case, where we dynamically search and find the item, the method will return an empty array.

Anyone at VMware has an eye on this?

As a workaround you may use somthing like this (removed exception handling for better readability) to get your operation object (took me 6 hours to find a working API call that is not bugged)

bindingId = iaasVM.virtualMachineID;

items = vCACCAFEEntitiesFinder.getCatalogResources(cafeHost);

for each(item in items)

{

    var itemBindingId = item.getProviderBinding().getBindingId();

    if(itemBindingId == bindingId)

    {

        var restClient = cafeHost.createRestClient(vCACCAFEServicesEnum.CATALOG_SERVICE);

        var response = restClient.get("consumer/resources/"+item.getId()+"/actions");

        var responseAsJSON = response.getBodyAsJson();

        for each (action in responseAsJSON.content)

        {

            if(action.bindingId === "Infrastructure.Virtual.Action.Destroy")

            {

                ressourceOperation = vCACCAFEEntitiesFinder.getCatalogResourceAction(item, action.id);

            }

        }

        break;

    }

}

Hope this helps.

Reply
0 Kudos
SeanKohler
Expert
Expert

In similar fashion... without going into REST client... I had solved it this way...

var myResources = Server.findAllForType("VCACCAFE:CatalogResource",stringName);

//var myResources = vCACCAFEEntitiesFinder.findCatalogResources(cafeHost,stringName);

for each (resource in myResources){
if (resource.getName() == stringName){
  System.log(resource.getName());
  resourceTarget = vCACCAFEEntitiesFinder.getCatalogResource(cafeHost,resource.getId());
  System.log(resourceTarget.getName());
  for each (operation in resourceTarget.getOperations()){
   System.log(operation.getName());
  }
}
}