VMware Cloud Community
IntMsh
Contributor
Contributor

NSX-v DynamicTypes plug-in V2 Installation fails with vRO 7

Hi everybody,

I'm having similar problems to this topic:

NSX-v DynamicTypes plug-in V2 Install Failed

Clean install of vRO 7.0.0.16989-3310032 with DynamicTypes 1.1.0.3209451

Packages:

dynamictypes-plug-in-generator-version-0.0.25.package

nsx-v-version-0.0.8.package

The packages had to be modified with hazenet'ssolution found here:

https://flowgrab.com/project/view.xhtml?id=49a97305-a6d6-4c81-a44f-a492c2299c34&download=true&downlo...

Due to a bug (?) with installing packages from Flowgrab with vRO 7.

Anyway, when running Plugin gen -1- install plug-in the workflow throws a validation error as seen below:

Screenshot_1.png

Looks like the namespace parameter is not bound:

Screenshot_2.png

Yet the workflow requires the "namespaces" parameter:

Screenshot_3.png

I guess I could fix this and simply bind a parameter with null value but it would probably mess up the import code where the namespaces are passed:

DynamicTypesManager.importConfigurationFromPackage(namespaces, file);

Anyway, what should be the namespace there? Any way to hardcode it or properly fix it? Maybe just pass an empty array?

Regards,

Mike

Reply
0 Kudos
12 Replies
iiliev
VMware Employee
VMware Employee

Hi,

I think the issue with non-bound parameters is fixed in some later build of Dynamic Types plug-in.

If I recall correctly, passing a null value will import all namespaces. Passing an empty array would not work.

I cannot open the flowgrab link but if the inventory picture at https://communities.vmware.com/docs/DOC-29032 is correct, then there should be a single namespace named "NSX".

Reply
0 Kudos
IntMsh
Contributor
Contributor

Okay, looks like passing a null value as namespace worked. The plugin did install properly. But I cannot proceed with running the Plugin gen -2- Add new host workflow.

I'm passing there values:

namespace - selected "NSX" namespace,

name "NSXManager",

host "https://<NSX_MANAGER_IP_ADDRESS>/",

no proxy, basic auth,

username "admin" and a password which I can log in to the NSX Manager with.

The workflow fails with following output:

[2016-03-01 02:00:16.491] [I] Workflow 'Add a REST host' (0) terminated with status 'failed'

[2016-03-01 02:00:16.523] [I] All workflows completed

[2016-03-01 02:00:16.630] [E] Target object does not support custom property

[2016-03-01 02:00:16.662] [E] Workfow execution stack:

***

item: 'Plugin gen -2- Add new host/item2', state: 'failed', business state: 'null', exception: 'Target object does not support custom property'

workflow: 'Plugin gen -2- Add new host' (8ed2b776-c243-4871-83c8-cd31684ceace)

|  'attribute': name=restHost type=REST:RESTHost value=__NULL__

|  'attribute': name=wf type=Workflow value=dunes://service.dunes.ch/Workflow?id='8F8080808080808080808080808080808080808001299080088268176866967b3'&dunesName='Workflow'

|  'attribute': name=parameters type=Array/Properties value=#{#Properties##[#authUserName#=#string#admin#+#oauth2Token#=#string##+#ignoreWarnings#=#boolean#true#+#operationTimeout#=#number#60.0#+#workstation#=#string##+#useProxy#=#boolean#false#+#accessToken#=#string##+#proxyHost#=#string##+#url#=#string#https://172.16.0.164/#+#authPassword#=#string#PASSWORD_WAS_HERE#+#accessTokenSecret#=#string##+#cons... Session#+#connectionTimeout#=#number#30.0#+#authentication#=#string#Basic#]##}#

|  'attribute': name=ignoreWarnings type=boolean value=true

|  'attribute': name=hostVerification type=boolean value=false

|  'attribute': name=workflowTokens type=Array/WorkflowToken value=#{#WorkflowToken#dunes://service.dunes.ch/WorkflowToken?id='2c908025531de7790153319ec2020d5a'&dunesName='WorkflowToken'#}#

|  'input': name=name type=string value=NSXManager

|  'input': name=url type=string value=https://NSX_MANAGER_IP_ADDRESS/

|  'input': name=authentication type=string value=Basic

|  'input': name=authUserName type=string value=admin

|  'input': name=authPassword type=SecureString value=__NULL__

|  'input': name=consumerKey type=string value=

|  'input': name=consumerSecret type=SecureString value=__NULL__

|  'input': name=accessToken type=string value=

|  'input': name=accessTokenSecret type=SecureString value=__NULL__

|  'input': name=connectionTimeout type=number value=30.0

|  'input': name=operationTimeout type=number value=60.0

|  'input': name=sessionMode type=string value=Shared Session

|  'input': name=oauth2Token type=string value=

|  'input': name=workstation type=string value=

|  'input': name=domain type=string value=

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

|  'input': name=proxyHost type=string value=

|  'input': name=proxyPort type=number value=null

|  'input': name=namespace type=DynamicTypes:DynamicNamespaceDefinition value=dunes://service.dunes.ch/CustomSDKObject?id='NSX'&dunesName='DynamicTypes:DynamicNamespaceDefinition'

|  'output': name=restHostOut type=REST:RESTHost value=null

*** End of execution st

Reply
0 Kudos
IntMsh
Contributor
Contributor

Okay, I've traced it up throught Add Rest Host to Manage SSL Certificate workflow. When passing the host parameter the workflow returns:

[2016-03-01 03:12:17.627] [I] url: https://IP_ADDRESS_HERE

[2016-03-01 03:12:17.636] [E] Provided url is invalid 'https://IP_ADDRESS_HERE'

[2016-03-01 03:12:17.737] [E] Workfow execution stack:

***

item: 'Manage SSL certificates/item1', state: 'failed', business state: 'null', exception: 'TypeError: Cannot call method "getCertificateInfo" of null (Workflow:Manage SSL certificates / Get URL certificates (item0)#14)'

workflow: 'Manage SSL certificates' (CC808080808080808080808080808080CA80808001299080088268176866967b3)

|  'attribute': name=errorCode type=string value=TypeError: Cannot call method "getCertificateInfo" of null (Workflow:Manage SSL certificates / Get URL certificates (item0)#14)

|  'attribute': name=hostValidator type=Any value=string#

|  'attribute': name=certificateInfo type=Properties value=__NULL__

|  'attribute': name=certificateHostName type=string value=

|  'attribute': name=hostName type=string value=

|  'attribute': name=installCertificates type=string value=

|  'attribute': name=certificateString type=string value=

|  'input': name=url type=string value=https://IP_ADDRESS_HERE

|  'input': name=proxySettings type=Properties value=__NULL__

|  'no outputs'

*** End of execution stack.

So it seems that the RESTHostValidator.validateUrl() function is throwing an error.

Okay so I've tested it like this:

var url = "https://amazon.com";

System.log("url: " + url);

try {

  hostValidator = new RESTHostValidator(url);

  hostValidator.validateUrl();

} catch (err) {

  System.error( "Provided url is invalid '" + url + "'" );

}

And tested it with new urls, with http/https w/ and w/o 'www', ip urls, full FQDNs. Everytime the function throws an exception. No url I provided is working so I'm guessing this function is bugged.

As far as I see the RESTHostValidator class is provided by HTTP-REST Plug-In so I cannot get to the code sadly to check it out further. HTTP-REST plugin that is installed in my vRO7 is:

REST 2.0.0.3217836, REST plug-in for vRealize Orchestrator

Reply
0 Kudos
IntMsh
Contributor
Contributor

Following this up:

The error is :

ReferenceError: "RESTHostValidator" is not defined.

I've downloaded the plugin from the vRO Control Center. Openned the .DAR file and explored it a bit. Seems that the RESTHostValidator Class is not present in the JAR file:

Screenshot_4.png

No wonder it's not visible from the Orchestrator:

Screenshot_5.png

Is there any way I could get a proper HTTP-Rest plug-in and upload it to my vRO installation?

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

Hmm, I think RESTHostValidator was removed a while ago, as well as Manage SSL Certificate workflow. I don't have this workflow in my vRO 7 appliance.

Could you right-click on Manage SSL Certificate workflow in vRO workflows tree view and execute References -> Find elements that use this element command to see where this workflows comes from (from which package)?

Reply
0 Kudos
IntMsh
Contributor
Contributor

Here are the outputs for add rest host and manage ssl certificates:

Screenshot_8.pngScreenshot_6.png

Well I did the install on a clean system. vRO7 appliance using MS SQL Server as DB and followed the deployment guide (with db population from vRO Control Center).

Additional info - it seems that the version of the workflows are quite ... old, one might say:

Screenshot_9.pngScreenshot_10.png

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

When you configured MS SQL DB, did you create a new empty database, or choose an existing database (possibly used by older vRO installation)?

Here are a couple of screenshots from my system. Just fresh OVF deploy; no additional configuration. There is no Manage SSL Certificates workflow, and Add a REST host workflow uses Import a certificate from URL family of workflows.

!

Reply
0 Kudos
IntMsh
Contributor
Contributor

No, the database was 100% clean. As I said, it was on a clean SQL installation. I created the DB myself. Double checked the proper SQL IP address just a second ago.

I have an idea. Maybe when I imported the packages some workflows were overwritten. I'll redeploy it asap and see if the problem persists on a very clean install Smiley Happy

Reply
0 Kudos
IntMsh
Contributor
Contributor

Ok I think I know where the failure occured. When importing package I must have accidentally checked the import all / overwrite workflows checkbox/selectbox. This is the only way the workflows could be overwriten.

After a clean install (using the internal DB but that doesn't matter) and importing it again seems to work ok. I was able to add the NSX Manager host without any issues.(note here - I passed the vCenter registration in vRO at this moment but it shouldn't be needed as I only want to test the NSX explorer)

But....

Even though the simple workflows like Get System CPU Info return proper information (meaning that authorization is ok):

Screenshot_12.png

The Dynamic Types show no entries (notice the lack of the expand arrow):

Screenshot_11.png

Even though I created a sample Edge:

Screenshot_13.png

Pure REST API call for edges returns that edge properly, yet Dynamic Types shows 0 items in every category.

Reply
0 Kudos
IntMsh
Contributor
Contributor

Yet another follow up:

I've created a sample workflow which uses the findAll() action from dynamicTypes to debug this. Passing "NSX.edge" as the type parameter returns a proper XML response but the parsing done by getEdgeObjectsProperties actions is wrong:

[2016-03-01 14:35:09.553] [I] ------------------------- end findAll edgeFolder returning 1 objects

[2016-03-01 14:35:09.574] [I] putInCache(NSX.edgeFolder.all,NSX.edgeFolder.0e3eeb62-9f4d-4c63-9c3c-a55a8e8cce63)

[2016-03-01 14:35:09.613] [I] GET : "https://172.16.0.164/api/4.0/edges"

[2016-03-01 14:35:09.711] [W] Not JSON, attempting to convert from XML

[2016-03-01 14:35:09.728] [I] Passing to getEdgeObjectsProperties:

Below we can see a truncated JSON input before parsing

[2016-03-01 14:35:09.730] [I] {"pagedEdgeList":{"edgePage":{"pagingInfo":{"startIndex":0,"pageSize":256,"sortBy":"id","totalCount":1,"sortOrderAscending":true},"edgeSummary":{id":"edge-2","state":"deployed","fqdn":"NSX-edge-2","vmNameOfActiveVse":"edge-test-0",,"objectId":"edge-2"}}}}

[2016-03-01 14:35:09.738] [E] Error in (Dynamic Script Module name : getEdgeObjectsProperties#3) TypeError: Cannot read property "data" from undefined

[2016-03-01 14:35:09.754] [E] Workfow execution stack:

***

item: 'New workflow/item2', state: 'failed', business state: 'null', exception: 'TypeError: Cannot read property "data" from undefined (Dynamic Script Module name : getEdgeObjectsProperties#3)'

workflow: 'New workflow' (5be7605c-d4c0-4869-ae8a-9b71808dc81f)

|  'attribute': name=type type=string value=NSX.edge

|  'attribute': name=actionResult type=Array/DynamicTypes:DynamicObject value=__NULL__

|  'attribute': name=att0 type=string value=

|  'no inputs'

|  'no outputs'

*** End of execution stack.

And the error points to the fourth line of the script:

Screenshot_14.png

Maybe this is the problem with the lack objects when listing them from DynamicTypes.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

I don't have NSX environment to validate it, but I see a few problems here:

The JSON string on line 7 in the first screenshot is not a valid JSON. It has at least 2 errors:

  • The id attribute of edgeSummary node has a closing quote but not opening quote character.
  • There is a duplicated comma character before objectId attribute

The properly formatted JSON string would look like the following

{"pagedEdgeList":{"edgePage":{"pagingInfo":{"startIndex":0,"pageSize":256,"sortBy":"id","totalCount":1,"sortOrderAscending":true},"edgeSummary":{"id":"edge-2","state":"deployed","fqdn":"NSX-edge-2","vmNameOfActiveVse":"edge-test-0","objectId":"edge-2"}}}}

Also, assuming this is the parameter jsonString passed as input of the action on the second screenshot, the fourth line of the script is not correct as it expects that the parsed object will have a top-level attribute edgePage which in turn has attribute data. But the JSON string provided above represents an object whose top-level attribute is pagedEdgeList which has an attribute edgePage (but edgePage doesn't have an attribute data).

So a valid code to query over the JSON object could be something like the following (an example to fetch the value of pageSize attribute)

var pagesize = JSON.parse(jsonString).pagedEdgeList.edgePage.pagingInfo.pageSize; // will return 256

So it appears that the NSX returns data that has different structure from that getEdgeObjectsProperties() action expects. I'm just guessing here, but it is possible that the plug-in is written against an older NSX version and you are using a newer NSX version where the format of this particular data object is slightly different.

Reply
0 Kudos
IntMsh
Contributor
Contributor

Yes. I've figured that already.

It seems that the API responses have changed a bit. Yet after fixing the getEdgeObjectsProperties() action the Dynamic Types inventory still remains empty. I digged a bit more around the code (findAll and findById from DynamicTypes) and I think it points to the conclusion that DynamicTypesManager.getObject function might be also faulty (type conversion problem there).

So the conclusion is the DynamicTypes / NSX-V v2 are NOT compatible with NSX 6.2.1 at the moment. Smiley Sad

cdecanini_‌ As a plugin maintainer could you look at this problem also?

Reply
0 Kudos