Wondering if someone out there may be able to point me to any resources/documentation regarding how to correctly configure our Jenkins instance to be able to run Orchestrator workflows. We have been able to download and install the VMWare vRealize Orchestrator plugin for Jenkins (VMware vRealize Orchestrator Plugin - Jenkins - Jenkins Wiki) and create jobs for a given Jenkins slave where we can successfully save workflows existing in our Orchestrator instance as build steps. When we try to run the build, the Jenkins console output appears as:
10:02:49 Started by user Anonymous
10:02:49 [EnvInject] - Loading node environment variables.
10:02:49 Building remotely on *sanitized*in workspace F:\jenkins\workspace\anon_orchestrator_create-a-snapshot
10:02:49 FATAL: Received fatal alert: handshake_failure
10:02:49 java.io.IOException: Received fatal alert: handshake_failure
10:02:49 at com.vmware.vro.jenkins.plugin.OrchestratorBuilder.perform(OrchestratorBuilder.java:95)
10:02:49 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
10:02:49 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761)
10:02:49 at hudson.model.Build$BuildExecution.build(Build.java:203)
10:02:49 at hudson.model.Build$BuildExecution.doRun(Build.java:160)
10:02:49 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:536)
10:02:49 at hudson.model.Run.execute(Run.java:1741)
10:02:49 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
10:02:49 at hudson.model.ResourceController.execute(ResourceController.java:98)
10:02:49 at hudson.model.Executor.run(Executor.java:374)
10:02:49 Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
10:02:49 at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
10:02:49 at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
10:02:49 at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1943)
10:02:49 at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1059)
10:02:49 at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1294)
10:02:49 at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1321)
10:02:49 at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1305)
10:02:49 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.j...
10:02:49 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:35...
10:02:49 at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOpe...
10:02:49 at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionMana...
10:02:49 at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
10:02:49 at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
10:02:49 at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
10:02:49 at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
10:02:49 at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
10:02:49 at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
10:02:49 at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
10:02:49 at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
10:02:49 at com.vmware.vro.jenkins.plugin.util.RestClient.executeRequest(RestClient.java:139)
10:02:49 at com.vmware.vro.jenkins.plugin.util.RestClient.httpGet(RestClient.java:77)
10:02:49 at com.vmware.vro.jenkins.plugin.OrchestratorClient.fetchWorkflows(OrchestratorClient.java:66)
10:02:49 at com.vmware.vro.jenkins.plugin.OrchestratorBuilder.perform(OrchestratorBuilder.java:87)
10:02:49 ... 9 more
10:02:49 [BFA] Scanning build for known causes...
10:02:49 [BFA] No failure causes found
10:02:49 [BFA] Done. 0s
10:02:49 Started calculate disk usage of build
10:02:49 Finished Calculation of disk usage of build in 0 seconds
10:02:49 Started calculate disk usage of workspace
10:02:50 Finished Calculation of disk usage of workspace in 0 seconds
10:02:50 Finished: FAILURE
Is there anyone who has done this before and can offer some advice? Many thanks...
Hi,
For security reasons, vRO 7.0.1 has limited connector protocols to TLSv1.2 and TLSv1.1. The other previously used protocols like TLSv1 or SSLv3 are disabled by default.
Looking at plug-in's source code (RestClient class), it seems it uses Apache's SSLContextBuilder without explicitly specifying a protocol, in which case it defaults to TLS. Now, if your Jenkins instance (and thus the plug-in) runs under Java 7, this will default to client code trying to connect using TLSv1 which is not supported by vRO server, and hence you'll get the handshake error.
So the first think is to check that Jenkins runs on Java 7. If this is the case, then switching it to run under Java 8 should fix the handshake issue.
If for some reason moving to Java 8 is not an option, then the alternatives are:
1) The plug-in code (RestClient class in particular) can be modified to explicitly request eg. TLSv1.2 protocol, or
2) You can lower security settings on vRO appliance to re-enable support for TLSv1 / SSLv3 protocols by adding them to the list with enabled protocols in /etc/vco/app-server/server.xml file and restarting vRO service.
Hi,
For security reasons, vRO 7.0.1 has limited connector protocols to TLSv1.2 and TLSv1.1. The other previously used protocols like TLSv1 or SSLv3 are disabled by default.
Looking at plug-in's source code (RestClient class), it seems it uses Apache's SSLContextBuilder without explicitly specifying a protocol, in which case it defaults to TLS. Now, if your Jenkins instance (and thus the plug-in) runs under Java 7, this will default to client code trying to connect using TLSv1 which is not supported by vRO server, and hence you'll get the handshake error.
So the first think is to check that Jenkins runs on Java 7. If this is the case, then switching it to run under Java 8 should fix the handshake issue.
If for some reason moving to Java 8 is not an option, then the alternatives are:
1) The plug-in code (RestClient class in particular) can be modified to explicitly request eg. TLSv1.2 protocol, or
2) You can lower security settings on vRO appliance to re-enable support for TLSv1 / SSLv3 protocols by adding them to the list with enabled protocols in /etc/vco/app-server/server.xml file and restarting vRO service.
Thanks to iilievIlian Iliev for the reply. Lowering the security settings does indeed seem to have helped. I am however, now seeing console output as follows on my jenkins builds:
11:47:07 Started by user Anonymous
11:47:08 [EnvInject] - Loading node environment variables.
11:47:08 Building remotely on Anonymous in workspace F:\jenkins\workspace\Anonymous
11:47:08 Starting Orchestrator workflow execution : fce6e738-aff8-4459-969d-eee8564fe086
11:47:08 FATAL: Unable to serialize com.vmware.vro.jenkins.plugin.OrchestratorCallable@4573b73d
11:47:08 java.io.IOException: Unable to serialize com.vmware.vro.jenkins.plugin.OrchestratorCallable@4573b73d
11:47:08 at hudson.remoting.UserRequest.serialize(UserRequest.java:169)
11:47:08 at hudson.remoting.UserRequest.<init>(UserRequest.java:63)
11:47:08 at hudson.remoting.Channel.call(Channel.java:751)
11:47:08 at com.vmware.vro.jenkins.plugin.OrchestratorBuilder.perform(OrchestratorBuilder.java:113)
11:47:08 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
11:47:08 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761)
11:47:08 at hudson.model.Build$BuildExecution.build(Build.java:203)
11:47:08 at hudson.model.Build$BuildExecution.doRun(Build.java:160)
11:47:08 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:536)
11:47:08 at hudson.model.Run.execute(Run.java:1741)
11:47:08 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
11:47:08 at hudson.model.ResourceController.execute(ResourceController.java:98)
11:47:08 at hudson.model.Executor.run(Executor.java:374)
11:47:08 Caused by: java.io.NotSerializableException: com.vmware.vro.jenkins.plugin.model.BuildParam
11:47:08 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
11:47:08 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
11:47:08 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
11:47:08 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
11:47:08 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
11:47:08 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
11:47:08 at hudson.remoting.UserRequest._serialize(UserRequest.java:158)
11:47:08 at hudson.remoting.UserRequest.serialize(UserRequest.java:167)
11:47:08 ... 12 more
11:47:08 [BFA] Scanning build for known causes...
11:47:08 [BFA] No failure causes found
11:47:08 [BFA] Done. 0s
11:47:08 Started calculate disk usage of build
11:47:08 Finished Calculation of disk usage of build in 0 seconds
11:47:08 Started calculate disk usage of workspace
11:47:08 Finished Calculation of disk usage of workspace in 0 seconds
11:47:08 Finished: FAILURE
In the spirit of trying to keep things as simple as possible while I try to get this going, the jenkins build doesn't actually *do* anything - all it does is include a build step that runs an orchestrator workflow. Similarly, I've tried running a workflow that contains no elements (thus, no input parameters need be provided) and a single element of a scriptable task that simply declares a variable and sets it's value (again, needing no input). No matter how simple - I consistently get console output as demonstrated above.
Any input as to how this may be remedied is most appreciated.
Well, the error message says it - the class com.vmware.vro.jenkins.plugin.model.BuildParam is not serializable. Looking at plug-in source code, the class indeed does not implement Serializable interface.
This requires code change and recompilation/new version release. I'll let Agila (plug-in's author) know about the issue; she probably doesn't monitor this forum.
A new version 2.0 of the plug-in has been released with a fix for serialization issue. Please give it a try.
Thank you (again) Ilian Iliev - We've been able to implement the latest release of this plug in, and had our first success!
It took a couple of tries (I had a few 'do-nothing' jobs, that passed no real payload between jenkins and orchestrator - which the two did not seem to like) but, once I tried a token 'do-little' job that carried a payload to orchestrator (a single parameter for a 'do nothing' scriptable task) the jenkins build indicated success.
...I'm off to try some useful 'do-something' jobs, in hopes that the success with 'do-little' jobs will translate. Thanks for your invaluable help.