VMware Cloud Community
qc4vmware
Virtuoso
Virtuoso
Jump to solution

Workflow or action to get the vRO version

Whats the best way to determine the vRO servers version number... I am trying to account for differences in how things are running between 6 and 7.  I found this example from burke but it is not working on version 7

var vROIP = Config.getNetworkInterfaces().getBindInterface();

var vROPort = Config.getNetworkInterfaces().getBindPort();

var getUrl = "https://"+vROIP+":"+vROPort+"/vco/api/about";

//get url

var urlObject = new URL(getUrl);

var aboutResult = urlObject.getContent() ;

// parse results

System.debug(aboutResult);

System.debug("============");

var aboutObj = JSON.parse(aboutResult);

System.debug("Version: "+aboutObj["version"]);

var version = aboutObj["version"];

System.debug("Build Number: "+aboutObj["build-number"]);

var build = aboutObj["build-number"];

System.debug("Build Date: "+aboutObj["build-date"]);

System.debug("API Version: "+aboutObj["api-version"]);

There does not seem to be a Config.getNetworkInterfaces method in 7.2

1 Solution

Accepted Solutions
igaydajiev
VMware Employee
VMware Employee
Jump to solution

Config.getNetworkInterfaces() method are not available in 7.2 but since they are used only for resolving the vrohost_ip:port of vRO server running the workflows probably you can directly use "locallhost" and remains only the port.  Which in case of standalone vRO is always 8281  

var vROPort = Config.getNetworkInterfaces().getBindPort();

=======

var getUrl = "https://localhost:8281/vco/api/about";

//get url

var urlObject = new URL(getUrl);

var aboutResult = urlObject.getContent() ;

// parse results

System.log(aboutResult);

System.log("============");

var aboutObj = JSON.parse(aboutResult);

System.log("Version: "+aboutObj["version"]);

var version = aboutObj["version"];

System.log("Build Number: "+aboutObj["build-number"]);

var build = aboutObj["build-number"];

System.log("Build Date: "+aboutObj["build-date"]);

System.log("API Version: "+aboutObj["api-version"]);

View solution in original post

7 Replies
igaydajiev
VMware Employee
VMware Employee
Jump to solution

Config.getNetworkInterfaces() method are not available in 7.2 but since they are used only for resolving the vrohost_ip:port of vRO server running the workflows probably you can directly use "locallhost" and remains only the port.  Which in case of standalone vRO is always 8281  

var vROPort = Config.getNetworkInterfaces().getBindPort();

=======

var getUrl = "https://localhost:8281/vco/api/about";

//get url

var urlObject = new URL(getUrl);

var aboutResult = urlObject.getContent() ;

// parse results

System.log(aboutResult);

System.log("============");

var aboutObj = JSON.parse(aboutResult);

System.log("Version: "+aboutObj["version"]);

var version = aboutObj["version"];

System.log("Build Number: "+aboutObj["build-number"]);

var build = aboutObj["build-number"];

System.log("Build Date: "+aboutObj["build-date"]);

System.log("API Version: "+aboutObj["api-version"]);

iiliev
VMware Employee
VMware Employee
Jump to solution

The same code can be used also with vRO embedded in vRA; the port is 443 instead of 8281 in this case.

qc4vmware
Virtuoso
Virtuoso
Jump to solution

So we have both embedded and external vRO servers.  Is there a way to easily distinguish this programmatically?  It would be super nice to simply have this information as part of a scriptable object or an object type for the configurator plugin.  I guess I can try port 8281 first and if that fails try 443 but thats messy.

Reply
0 Kudos
igaydajiev
VMware Employee
VMware Employee
Jump to solution

I am not aware of such method. 

Will open internal ticket to extend scripting API with method providing same server info as one available trough REST.

Could you elaborate a bit around your use case. It is interesting to me which part of server node info is needed and how it is used.

qc4vmware
Virtuoso
Virtuoso
Jump to solution

I can think of a number of scenarios where I would want the vRO version number.  If I am using vRO to manage aspects of my environment as a whole that would likely be a key part of action I might want to take.  For instance a workflow that simply reports on my vRO servers (we have 8 at this point) to check on security patches that are released.  In my current case I hit an issue related here VcPlugin.getAllVirtualMachines(null, "xpath:name='" + vmName + "'") jxpath expression {} does not ev... where my 6.0.5 environment seems to require a different xpath string than in my 7.2 environment.  My 6.0.5 environment is all embedded vRO as part of vRA.  I'm not sure if it is the vRO version or the version of the vSphere plugin that is the source of the problem but I modified my workflow to account for the vRO version for now and issue commands that work in that environment.  Over the years I have hit quite a few vRO version specific bugs and having the ability to account for that makes it easier for me to move forward and take advantage of the new features while accounting for the occasional bug if it happens to be something I can code around.  Sometimes its not bugs its a design change or maybe a change in one of the plugins.  In our environment more than likely all vRO servers of a specific version also have all the same plugin versions so keying on that makes it simple.

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso
Jump to solution

Oh... I also wanted to add that using port localhost:8281 works on both my 7.2 stand alone and 6.0.5 embedded vRO servers in vRA 6.2.5.

Reply
0 Kudos
igaydajiev
VMware Employee
VMware Employee
Jump to solution

Make sense.

I was curious since when using about REST API call in case of clustered environment call will get redirected to particular node and you get the info of particular node from the cluster. But It is not required that all nodes from the cluster run same vRO version. Having the node info available in the scripting reporting current node about information seems like nice extension!

Thanks for the info!