VMware Cloud Community
randomname
Enthusiast
Enthusiast

vAPI issues

One of the things I do as a standard thing in all of my workflows is explicit external logging of attributes and input parameters. Stripping down the code to the bare minimum, it's:

var inParamsWf = workflow.currentWorkflow.inParameters;

var inParamsWfToken = workflow.getInputParameters();

for (var i = 0; i < inParamsWfToken.keys.length; i++) {

    for (var j = 0; j < inParamsWfToken.get(inParamsWfToken.keys[i]).length; j++) {

        var eventMessage = inParamsWfToken.keys[i] + "[" + j + "]=" + inParamsWfToken.get(inParamsWfToken.keys[i])[j];

        System.getModule("com.snip.general").newLogEvent(eventMessage,"info",true,null);

        }

    }

When encountering a tag, this used to properly log to my target like:

[11-18-2019 20:53:50 UTC] [INFO] tag=DynamicWrapper (Instance) : [com_vmware_cis_tagging_tag__model]-[class com.vmware.o11n.plugin.vapi.model.VapiObjectWrapper] -- VALUE : com.vmware.o11n.plugin.vapi.model.VapiObjectWrapper@734331fa[{category_id=urn:vmomi:InventoryServiceCategory:92911c61-ea01-4a3a-8bfe-5db733aa835d:GLOBAL, name=snip, description=, id=urn:vmomi:InventoryServiceTag:09480590-db58-4636-a77b-d7c59a623ce0:GLOBAL, used_by=[Ljava.lang.Object;@69f1b6b8}]

At some point in the past couple of months something changed which resulted in this code breaking when the input parameter encountered is of type com_vmware_cis_tagging_tag__model. I have not done enough testing to see if it extends to other tag related objects or other objects provided by vAPI. Now the default vRO logging throws:

[2020-01-21 09:05:36.222] [E] Cannot create com_vmware_cis_tagging_tag__model object : java.lang.NullPointerException

[2020-01-21 09:05:36.231] [E] Workflow execution stack:

***

item: 'New workflow27/item1', state: 'failed', business state: 'null', exception: 'Cannot create com_vmware_cis_tagging_tag__model object : java.lang.NullPointerException'

workflow: 'get tag loop' (56cfb3e4-43f7-4eff-997a-6badbb3a6788)

|  'attribute': name=uri type=string value=https://snip/api

|  'attribute': name=val type=string value=01083

|  'attribute': name=cat type=string value=Loc.Id

|  'attribute': name=tag type=VAPI:com_vmware_cis_tagging_tag__model value={"@class":"com_vmware_cis_tagging_tag__model","category_id":"urn:vmomi:InventoryServiceCategory:46f42579-a698-42d4-9c24-1e91232bd9ed:GLOBAL","name":"01083","description":"","id":"urn:vmomi:InventoryServiceTag:54a85756-3c1a-498e-bc35-5e8339c73f12:GLOBAL","used_by":[]}

|  'attribute': name=counter type=number value=0.0

|  'input': name=loop type=boolean value=false

|  'input': name=loops type=number value=1.0

|  'input': name=wait type=number value=1.0

|  'no outputs'

--workflow: 'New workflow27' (692f9b87-334f-47b1-b93e-c417f2be8887)

  |  'input': name=arg_in_0 type=VAPI:com_vmware_cis_tagging_tag__model value={"@class":"com_vmware_cis_tagging_tag__model","category_id":"urn:vmomi:InventoryServiceCategory:46f42579-a698-42d4-9c24-1e91232bd9ed:GLOBAL","name":"01083","description":"","id":"urn:vmomi:InventoryServiceTag:54a85756-3c1a-498e-bc35-5e8339c73f12:GLOBAL","used_by":[]}

  |  'no outputs'

  |  'no attributes'

*** End of execution stack.

Since the last time it worked, vCenter, the vSphere plugin for vRO, and vRO itself have all been updated, so I'm not sure to which it is related.

Current vCenter verison is 6.5.0.30000-14389939. Current vRO vSphere plugin version is 6.5.0.15225986. Current vRO version is 7.4.0.15273518. vAPI plugin is 7.4.0.7235596, which is what came with vRO. I do not recall the previous versions of each when everything was working, though vCenter was 6.5.something and vRO was 7.4.something.

Are there any known issues between the aforementioned components which may result in this type of behavior? Just from looking at the proper logging versus the error, I see that "used_by" parameter is populated in the good log and absent in the error. And it refers to Java, which is the error being thrown by vRO.

For now I can probably add exceptions to my logging action based on the parameter type, but I don't know how many different types I could end up finding which behave this way now, so it could just go on and on and on.

Reply
0 Kudos
7 Replies
iiliev
VMware Employee
VMware Employee

Are you getting this error only for tag "01083", or also for other instances of type 'com_vmware_cis_tagging_tag__model'?

I'll try to reproduce the error in my environment. If possible, could you export and share your workflows (just to make sure that I'll be testing with exactly the same code)?

When you say that 'used_by' is absent from the error, do you mean that there are some vCenter objects that are tagged with this tag and so 'used_by' is expected to contain some non-empty data? If so, do you know what are the types of vCenter objects tagged with it? Also, if you go to vSphere Web client, do you see these objects shown as tagged with this tag?

Reply
0 Kudos
randomname
Enthusiast
Enthusiast

All tags I've tried. If the workflow about which I am pulling data has an input parameter of that type with a value assigned, this is the result.

What I mean about "used_by," is that back when things were working, the output had that property populated. I don't know what it is and its value isn't significant to me. It looks like some kind of internal reference. What caught my eye is that in the working output it contained data, while in the error output it doesn't. That just struck me as odd. As if perhaps there is now some missing reference to necessary code somewhere.

I've attached a package containing basic workflows illustrating the issue. Code has been stripped down to bare minimum. Run test1 which calls test2. Test2 tries to log itself. Test1 is only there to pass a valid tag to test 2 since you can't pick a tag interactively at run time.

Reply
0 Kudos
LukasWe
Enthusiast
Enthusiast

I am just sharing my personal experience with vAPI and I doubt that this is also related to your issue.

All of my code is functional but every now and then I get also this weird NullPointerException from vAPI when i want to read or create tags.

The only thing worked for me is to recreate the vAPI connection from vRO to the vCenter.

Reply
0 Kudos
randomname
Enthusiast
Enthusiast

Started getting those recently too. Different from the issue of this thread, but vAPI related nonetheless. What I've found is that I'll be able to execute tag related methods for a short while, then they all start failing. If I wait a while (5-15 minutes? haven't timed it) sometimes they'll start working again. If I restart the vAPI service on vCenter, they seem to start working temporarily again immediately. I've tried playing with the largely undocumented vAPI service properties, but haven't had much luck. I just ended up taking the lazy, ham fisted way out of putting delayed retry loops in all my tagging actions in vRO.

Again, different issue than this thread.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

vAPI has some built-in rate limiting of the incoming requests. Sounds like you might be reaching such limits.

For the other errors mentioned in this thread - I can make and upload a new build of vAPI plug-in, built against newer version of vAPI runtime libraries, in case you are willing to test if the issues you are hitting are resolved there.

Reply
0 Kudos
randomname
Enthusiast
Enthusiast

I would definitely be willing to test that, provided it would be otherwise considered a stable release aside from the issue I am attempting to resolve.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

I uploaded a newer build of vAPI plug-in - version 7.5.1-15648750. It is available for download at https://communities.vmware.com/docs/DOC-35527 page.

The only change in this build is that vAPI runtime libraries are updated to version 2.15.0. There are no changes in the source code or in the bundled workflows.

Reply
0 Kudos