Tag: vRealize Automation

VMware cloud account validation failed – alternative workaround on KB88531

Recently we had an issue with the validation of a VMware cloud account in vRA. The validation didn’t work.
A colleague at the customer site found the correct VMware KB artikel that addressed this issue ( it is KB article 88531)
This post is about an alternative approach for the same workaround mentioned in the KB article. This is not an in-depth article. You should have knowledge about vRA and using REST API calls.

Issue

The issue is that the certificate info has not been stored in the cloud account.
And this can happen when the vCenter SSL certificate is renewed, and in vRA you accept the new certificate, but you didn’t hit the ‘SAVE ‘ button.
When accepting the new certificate, you stored it in the certificate store of vRA. But because you didn’t hit save, that info wasn’t stored with the cloud account registration.
According to the article this has been solved in vRA 8.9 and for prior versions there is a workaround

Workaround

The workaround is correct. But what I don’t like about it, is that there is no explanation about what you are doing.
The workaround uses the REST API interface of vRA to store the correct certificate with the cloud account. And if they would have mentioned that, maybe the reader would think… wait…. REST API…. can I use the swagger interface…..

Yes you can.
The API calls we need are:

  • GET /iaas/api/cloud-accounts
    To find the cloud-account-id of the vCenter Cloud Account we are going to update
  • PATCH /iaas/api/cloud-accounts/{cloud-account-id}
    To store the new certificate information with the vCenter Cloud account

Alternative

  1. Store the vCenter certificate (including the chain) as a PEM file.
  2. Go to the swagger ui (which can be found at {root-url}/automation-ui/api-docs/
  3. Go to the ‘Infrastructure as a Service section
    In this section you will find the API calls we need.
  4. Authenticate with vRA using a Bearer token.
    (Tip: you can get a Bearer token using the REST API calls on the swagger ui and/or create a vRO action to get a Bearer token)
  5. Search for the cloud account id by using the ‘GET /iaas/api/cloud-accounts’
  6. Convert the PEM file to a single line where the line ends are replaced with \n
  7. update the cloud account with the new certificate information using the ‘PATCH /iaas/api/cloud-accounts/{cloud-account-id}? apiVersion=2021-07-15’ API call.
    (note: using the url parameter apiVersion is crucial)
    You should get a HTTP status code of 202 for confirmation.
  8. run the validation of the cloud account in vRA, it should work now

dipping my toes in vRA 8

re-visiting an old friend ?

I’ve been quite on my blog for the last half year. That is what moving to a new house, seeing my son growing up, renovating a bathroom, setting up my home automation etc… will do…
So at the last day of 2021, looking to the morning sky from my office at home, I decided to blog about my reintroduction experience with vRA 8

view from my attic

Yeah, reintroduction.

A few years ago I followed the VMware ICM (installation, configuration and management) course for vRA 7. Five days of learing about fabric groups, blueprints, orchestrator, the several VMs needed to build a vRealize Automation platform. By trade I’m a developer / automation engineer. The course was more a meaning to an end. But that end never happened. Yeah I’ve been building a vRA 7 platform. And on another assignment, rescuing a vRA 7 platform ( it was falling apart)… But really developing automation with vRA.. Never happened.
And my warm feelings for vRA 7 went away. A complex platform, a memory game in finding the correct terminology and links in the vRA portal… and that awfull java client for orchestrator. No succes stories for me.

Until

Until this year…
I’m working with a customer who has already a vRealize platform in place, but needs support in developing. In helping their administrators developing a developer mindset. And they have vRA 8

vRealize automation 8

Of course I had seen VMware’s presentation about vRA 8. And to be honest I started to become positive about vRA. No mix of appliances and windows VMs, no MS SQL VM… just one type of appliance, running kubernetes and distributed the several services over kubernetes pods.
vRA8 is underneath the hood a completely different than its predecessor. And no java client. And the principe that everything should be code…

In the last two weeks I’ve (with some help) deployed a new vRA 8 platform, and developed some automation, using the exisiting vRA 7 platform. We decided not to use the migration tool. But to rebuild the functionality. The main reason for this is the different approaches between vRA 7 and 8.
vRA 8 is focused on tag policy driven placement. Meaning you tag resources with several kind of metadata, like enviroment (DMZ,Dev,Production,Test) , OS, storage SLA, backup SLA. And you use constraints in blueprints and projects to guide the deployment.
You use vRO actions as external sources for option values, default values in the vRA request forms to help the end user in making selections.
You don’t develop one big monolithic automation, but need to slice it up in smaller parts. Thinking of ‘can I reuse it’, ‘can I make it more task general and dynamic’, etc.
And in the end you have some simple workflows and blueprints, but build a catalog with dynamic items, helping the administrator and/or developers in deploying VMs

My experience with developing in vRA 8 is a positive one. As for any language or automation platform, the main points to take away are:

  • find out how some programming constructs should be set up, like if…then…else, for..loop, regular expressions etc…
  • learn to code structured. Use readable names for variables, constants, objects etc… Use comments in your code to highlight, explain what the next line of instructions do.
  • The more high level your code is, the more you should use comments to explain what that code, workflow should do.
  • Learn by failing… take one function you are trying to use, build a new workflow around it, and test it… yes it can be time consuming… but you’ll learn
  • work with other developers, learn from their way of structure code. From their approach to automation
  • First try to get a picture of what needs to be automated, describe it in manual actions, how would an administrator solve this task by hand ?
    Try to get a broader sence of how the administrators are working , and ask about why things are as they are, what is the reason / decision for the way of working…..
    This is one of the hard parts of automation. Don’t start right away on the keyboard, but try to understand what is being asked to automate

Final

As you can tell, my experiences with vRA8 are positive. You need to invest time to understand the platform… but it makes more sense then vRA7 did. And it is completely different.
One of the main challenges with automation is, selling it to the organisation… and making it donkey proof… it takes time… take small steps so the changes for succes are bigger. And celebrate them.

%d bloggers like this: