Earlier in the year I stood up an expandable deployment of vRealize Automation (following this blog post). I’ve finally had time over the last week or so to focus on this new (to me) technology!
I’m starting to play around and really enjoying myself while at the same time becoming incredibly frustrated when I can’t accomplish something as quickly as I want to. I know there’s a learning curve… I desperately want to do the awesome stuff! Walk before you run, I suppose. At the very least, I had a moment the other night to think back on how the experience thus far is very similar to beginning my career in IT.
I’ve managed to automate a client/server deployment complete with dependencies and successful registrations of clients to server systems! It’s not super exciting, but I’ll take it as a win for now. It means that I’m picking up momentum.
Now for the point of the post: It came time for me to start playing with vRealize Orchestrator so that I can create some actions that will determine which version of Software Component is to be installed (blog post about that later, I hope). I deployed an External vRealize Orchestrator and intended to follow this blog post to set something up and begin to toy with concepts.
I followed the blog post step by step, but couldn’t get the desired results. I kept receiving an error for “System exception” which wasn’t as helpful as I had hoped.
I happened upon a blog article elsewhere that recommended checking the status of the catalina.out log file on the vRA appliance. I found that I was in the midst of some certificate errors!
[ÜTC:2018-07-24 18:28:14,254 Local:2018-07-24 18:28:14,254] vcac: [component="cafe:properties-service" priority="ERROR" thread="tomcat-http—38" tenant="mueller-tech" context="9WAnN224" parent="9WAnN224" Token=""] com. vmware.vcac.platform.rest.client.error.ResponseErrorHandler.handleRestError:113 - [Rest Error]: {Status code: 500}, {Error code: 50505} , {Error Source: null}, {Error Msg: System exception.}, {System Msg: I/O error on POST request for "https://vro:8281/vco/api/actions/com.mueller-tech.library.dropdowns/displayTemplatesFromFolderlD/executions/": java.security.cert.CertificateException: Untrusted certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted certificate chain.}
I figured that replacing this certificate would be quick and easy, but I failed miserably to complete this effort. Try as I may (via many different blog articles, how-to’s, and various other rituals), I couldn’t get a certificate to imported properly after far too long. I’ll revisit it when I’m not so frustrated.
I gave up and decided to just use the internal vRealize Orchestrator instance. I registered a new Orchestrator Endpoint and eventually found that I couldn’t communicate properly with the Internal Orchestrator the same way that I had with the External Orchestrator. Earlier in the day, I had found that I couldn’t communicate with the External Orchestrator because I had left out the required port for reaching the system. With the Internal Orchestrator, I couldn’t reach the system because I included the port. I thought I had learned my lesson!
I found that for the External Orchestrator Endpoint I needed to use https://vro-name.com:8281/vco. The Internal Orchestrator Endpoint ended up being as shown in the graphic, https://vro-name.com/vco. This happened mostly accidentally as I had already been in the catalina.out log file on the vRA appliance. We’ll just call it serendipitous.
It’s been a challenging day for my orchestration attempts. I feel like I lost a ton of time on this today. In the end, I at least got the drop-down from the blog post working. Better yet, I have some notes on how I hope to use this experience as a catalyst to other dynamic properties for Software Components. Maybe the lost time wasn’t so bad after all.