Grouping Custom Properties in Cloud Templates

When working with cloud templates, it is common to have a large number of custom properties that need to be set. These properties can be grouped logically into categories to make them easier to manage and maintain. In this article, we will explore the benefits of grouping custom properties and how to do it in your cloud templates.

Benefits of Grouping Custom Properties

—————————————

Grouping custom properties has several benefits, including:

### Easier Maintenance

When custom properties are grouped logically, it is easier to maintain and update them. You can make changes to one property without affecting the others.

### Improved Readability

Grouping custom properties makes it easier to understand the configuration of your cloud templates. It helps to reduce complexity and improve readability.

### Better Organization

Grouping custom properties allows you to organize your configuration in a more logical and structured way. This can help to reduce confusion and errors.

### Extensibility

When custom properties are grouped logically, it is easier to extract values for use in extensibility actions. Your custom properties are provided as objects within an array, which is simple to iterate through from vRO or an ABX action.

Grouping Custom Properties in YAML

————————————-

To group custom properties in your cloud templates, you can use nested objects. For example, you can create a resource object with nested properties, and then group your custom properties within those nested properties. Here is an example of how to group custom properties in a cloud template YAML file:

“`

formatVersion: 1

inputs:

businessUnit:

type: string

title: Business unit

vmNotesEntry:

type: string

title: VM Notes entry

resources:

Cloud_vSphere_Machine:

type: Cloud.vSphere.Machine

allocatePerInstance: true

properties:

cmdbProperties:

– deploymentName: ${env.deploymentName}

deploymentDate: ${env.requestedAt}

requestor: ${env.requestedBy}

businessUnit: ${input.businessUnit}

deploymentProperties:

– vmNotesEntry: ‘${input.vmNotesEntry}’

operatingSystemType: ‘linux’

image: ubuntu

cpuCount: 1

totalMemoryMB: 8192

storage:

constraints:

– tag: storage.profile:gold

networks:

– network: ${resource.Cloud_vSphere_Network.id}

assignment: static

“`

In this example, we have created two groups of custom properties: `cmdbProperties` and `deploymentProperties`. The `cmdbProperties` group contains properties that are used to populate a CMDB, while the `deploymentProperties` group contains properties that are used to configure the deployment.

Conclusion

———-

Grouping custom properties in your cloud templates can help to improve maintenance, readability, and organization. By using nested objects to group your custom properties, you can make it easier to extract values for use in extensibility actions. Standards should not be understated. So go and give your YAML code a spring clean and de-clutter! You will feel much better for it afterwards.

Creating an ABX Action to Raise a Jira Ticket on Deployment Failure

As a CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders, I love automation and the power it has to streamline processes and improve efficiency. Recently, I challenged myself to create an ABX action that would raise a Jira ticket when a deployment fails. Here’s how I did it and what I learned along the way.

First, I needed to install the atlassian-python-api library, which is required for interacting with Jira. Once I had installed the library, I created three action constants: one for the Jira URL, one for a Jira user account, and finally, an encrypted one for the Jira account password.

Next, I added new inputs for each of these action constants, so that the user can enter the necessary information to raise a Jira ticket. I also set up the action to be triggered on one event subscriptions, specifically Deployment completed. To ensure that the action is only triggered when a deployment fails, I used a Condition filter to check if the deployment status is “failed”.

With all of the pieces in place, I tested the action and was thrilled to see that it worked as expected! When a deployment fails, the Jira ticket is raised automatically, saving time and effort for my team.

This use case shows the potential for further integration between Jira and vRA8. By automating the process of raising a Jira ticket when a deployment fails, we can improve our incident management processes and ensure that issues are addressed quickly and efficiently.

In conclusion, creating an ABX action to raise a Jira ticket on deployment failure was a fun and educational challenge. It demonstrates the power of integration between Jira and vRA8, and highlights the potential for further automation in our IT processes. As a CIO, Automation Practice Lead, and guitarist, I will continue to explore new ways to leverage automation and improve efficiency in my teams.

—

VMware vRA8 Cheat Sheet

Welcome to the VMware vRA8 cheat sheet! This document is designed to provide a quick reference guide for common tasks and questions related to vRA8. It will evolve over time to cover more topics and become a single source for all things you forget, common questions with answers, and anything else that might be useful.

vRA8 FQDN Links

—————-

To access the vRA8 Control Center, use the following link in your chosen web browser:

https:///vco-controlcenter

To access the vRA8 Automation UI API Documentation, use the following link:

https:///automation-ui/api-docs/

Note: Replace with your vRA8 FQDN.

Day 2 Actions for vSphere

—————————

If you’re looking for a simple Day 2 action example for vSphere, check out the following link:

How to create a Cloud Assembly resource action to vMotion a virtual machine (vmware.com)

Critical Vulnerabilities in Apache Log4j

—————————————–

Recently, critical vulnerabilities in Apache Log4j were publicly disclosed, which impact VMware products. To learn more and what to do about it, follow this link:

Cloud Assembly Resource Flags for Requests (vmware.com)

Cloud Assembly Expression Syntax (vmware.com)

Quick Tips and Shortcuts

————————-

Here are some quick tips and shortcuts to help you work more efficiently with vRA8:

* Select multiple lines and then hold down the Ctrl key and press K followed by C to comment them out.

* To uncomment, hold down the Ctrl key and press K followed by U.

* Select multiple lines and then press the Tab key to indent them.

* To remove the indent, select the lines and then press the Shift key and the Tab key simultaneously.

That’s it for now! We hope you find this cheat sheet helpful in your vRA8 journey. Stay tuned for more updates and additions as we continue to evolve this document over time.

—

Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders, loves IT, automation, programming, music, and is the copyright owner of AutomationPro 2018.

VMware vRealize Suite Lifecycle Manager 8.6: Outbound Notifications – A Game Changer!

The latest release of VMware vRealize Suite Lifecycle Manager (8.6) has introduced a new feature that promises to revolutionize the way we receive updates and notifications from the platform. Say goodbye to the days of manually checking for updates and hello to a more streamlined and automated process with Outbound Notifications!

Configuring Outbound Notifications is easy and straightforward. You can choose from three methods to receive notifications: Microsoft Teams, Slack, or email. If you opt for email, you’ll need to provide the following details:

1. SMTP server address

2. SMTP server port

3. SMTP username and password (if using a secured SMTP server)

4. Your Lifecycle Manager appliance will need access to the internet (through a configured proxy server is ok)

Once you have entered all the details, ensure you send a test email message to confirm that everything is working as expected. Don’t forget to hit save!

Configuring SMTP Server Settings

To configure your SMTP server settings, head into the Settings page of the Lifecycle Manager appliance and select the “SMTP” option from the left-hand menu. Enter the required details, such as the SMTP server address, port, username, and password.

Configuring Outbound Notifications

To configure outbound notifications, head back into the Settings page and select the “Outbound Notifications” option. Choose your desired frequency (daily is a good starting point for testing) and enter your recipients list. Select the notification triggers you want to receive, such as product updates, license health updates, or all notifications. Hit save, and you’re done!

Example Email Received

Here’s an example of what you might receive in your inbox:

Subject: vRealize Suite Lifecycle Manager Update Notification

Dear [Your Name],

This is a test email notification from VMware vRealize Suite Lifecycle Manager 8.6. You have selected to receive notifications via email for the following triggers:

* Product Updates

* License Health Updates

Please note that this is just a test email and you will only receive actual notifications if there are updates or changes to your vRealize Suite products.

—

As great as this new feature is, there are a few bits missing from the roadmap that would make it even more powerful. For instance, it would be fantastic if product update notifications could go to our operational teams and license health updates could go to our licensing team. However, this is a great step in the right direction, and we can expect even greater benefits in the future.

In conclusion, VMware vRealize Suite Lifecycle Manager 8.6’s Outbound Notifications feature is a game changer for automation and IT professionals who want to stay on top of their product updates and notifications without having to manually check the platform. With its ease of use and flexibility, this feature promises to revolutionize the way we work with vRealize Suite products.

—

Paul Davey is CIO at Sonar, Automation Practice Lead at Xtravirt, and a guitarist in The Waders. He loves IT, automation, programming, and music.

As I settled back into work after the holiday break, I was greeted with a familiar yet frustrating issue in my home lab: vRA8 was not behaving as expected. After some investigation, I discovered that the root cause of the problem was a full /var/log directory, consuming 100% of the available space on the volume.

At first, I thought that simply removing some of the older log files would resolve the issue. And indeed, after cleanly shutting down and rebooting, the problem was temporarily resolved. However, I knew that this was not a sustainable solution, as I needed to keep the logs for troubleshooting and auditing purposes.

To prevent this issue from happening again in the future, I decided to investigate enlarging the volume. After some research, I found an article by Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. The article outlined a step-by-step approach to expanding the /var/log directory and resolving the issue.

According to the article, the first step was to identify the current size of the /var/log directory using the command “du -sh /var/log”. This command provides a summary of the disk usage for the specified directory. In my case, the output showed that the /var/log directory was consuming 100% of the available space on the volume.

The next step was to create a new partition for the /var/log directory using the command “sudo df -h /var/log”. This command provides a summary of the disk usage for the specified directory and also shows the percentage of the total disk usage. In my case, the output showed that the /var/log directory was consuming 100% of the available space on the volume, which confirmed my initial diagnosis.

Once I had identified the current size of the /var/log directory and confirmed that it was full, I could proceed with enlarging the volume. The article recommended using the “resize2fs” command to expand the partition. However, when I ran this command, I received an error message indicating that the partition was not mounted.

To resolve this issue, I needed to unmount the partition before attempting to resize it. I did this by running the command “sudo umount /var/log”. Once the partition was unmounted, I could proceed with resizing it using the “resize2fs” command.

After running the command, I received a confirmation message indicating that the partition had been successfully resized. To verify that the /var/log directory had been expanded, I ran the command “du -sh /var/log” again. This time, the output showed that the /var/log directory was no longer full and had freed up some space on the volume.

In conclusion, this experience taught me the importance of regularly monitoring and maintaining my home lab environment to prevent issues such as this from occurring. Additionally, I learned a valuable lesson about the importance of keeping track of disk usage and enlarging partitions as needed to ensure that the system remains healthy and functional.

Overall, this experience reinforced the importance of proactive maintenance and monitoring in maintaining a healthy and functional home lab environment. By following the steps outlined in the article and taking preventative measures, I was able to resolve the issue and ensure that my home lab continued to function optimally.

As a software developer, I have been asked many times about my coding habits and styles. In this post, I would like to share some of my thoughts on how to code effectively and efficiently in vRO (vRealize Automation).

First and foremost, keep it simple. Coding is a continuous learning process, and you should always strive to simplify your code whenever possible. Don’t get emotionally attached to the code you’ve just written; go back and simplify it, make it easier to read, and consume. The biggest benefit you can give to yourself and your peers is to make your code easy to consume and reusable.

When developing code, think about writing code that solves a generic problem, not just the exact issue at hand. This approach will make your code more versatile and reusable in different contexts. Imagine working on projects with hundreds of commits per month, without any code comments. The code should explain itself; why is this done? Why is it so backwards?

To avoid such issues, comment your code, please! Fill your debug console with row after row of output showing the various objects and properties being managed by your code. This will make it easier to debug when something goes wrong.

Use source control to store your code and batch up your work into small pieces, committing often. This simplifies bug fixing later on, makes it easier to review code changes, and tracks where you are and what you’re working on. Treat source control with respect and use it properly; it will reward you well.

Now, let’s look at an example of creating twenty example vm objects to test a method. Instead of constructing each object individually, we can create an array of twenty vmObjects using a function call. This approach is not only more readable but also reusable and adaptable to different use cases.

In addition to the above practices, consider reading release notes to see what changes have been introduced that may streamline your code. Embracing new syntax and abilities can make your life easier. Don’t be afraid to ask for help from peers or relevant communities. No one has seen it all! Asking for help can lead to problem-solving together, learning something new, or helping someone else learn. There is no negative in asking for help.

In conclusion, coding in vRO (vRealize Automation) or any other language should be about keeping it simple, reusable, and adaptable to different contexts. Remember to comment your code, use source control, and embrace new functionality and practices that streamline your workflow. Don’t be afraid to ask for help when needed, and always stay up to date with the latest releases and features.

Recently, I have been helping a customer replace their self-signed Management Agent certificate in vRA7.6 with a new self-signed one (old one is expiring). To be clear, this is the Management Agent certificate on the Iaas servers. VMware provides documentation on how to replace the certificate, but here are a few hints on the process.

Firstly, obtain the Management Agent identifier on each of the Iaas nodes where you will be replacing the certificate. You can do this by opening the Management AgentVMware.IaaS.Management.Agent.exe.config file. Make a note of the . The last part is what you will need for the -nd parameter when following the VMware documentation.

Next, obtain the SSL thumbprint needed for the -tp parameter. You can find this in the same file (Management AgentVMware.IaaS.Management.Agent.exe.config).

To execute the command, make sure you run it in an elevated command prompt. Remember that everything you enter is case sensitive. If the machine name is ABC101, entering abc101 will not work!

Before we dive into the process, let me provide some context. vRA7.6 provides a feature called Management Agent, which allows you to manage and automate your vCenter environments. The Management Agent certificate is used to establish trust between the Management Agent and the vCenter server. When the certificate expires, it needs to be replaced with a new one to maintain this trust.

Now, let’s get started with the process of replacing the self-signed Management Agent certificate in vRA7.6.

Step 1: Obtain the Management Agent Identifier

Open the Management AgentVMware.IaaS.Management.Agent.exe.config file and look for the tag. The identifier is located within this tag, and it looks something like this:

Note down the entire identifier, as you will need it for the -nd parameter later.

Step 2: Obtain the SSL Thumbprint

Open the same file (Management AgentVMware.IaaS.Management.Agent.exe.config) and look for the tag. The SSL thumbprint is located within this tag, and it looks something like this:

Note down the entire thumbprint, as you will need it for the -tp parameter later.

Step 3: Execute the Command

Make sure you run the command in an elevated command prompt. The command to replace the self-signed Management Agent certificate is as follows:

vmware-vipr-iaas-management-agent -nd -tp

Replace with the identifier you noted earlier, and replace with the thumbprint you noted earlier.

For example, if your Management Agent identifier is “abcdefg-hijkl-mnopqrst” and your SSL thumbprint is “xxxxxx-xxxx-xxxxx-xxxxx”, the command would look like this:

vmware-vipr-iaas-management-agent -nd abcdefg-hijkl-mnopqrst -tp xxxxx-xxxx-xxxxx-xxxxx

After running the command, the new certificate will be installed on the Iaas servers, and the Management Agent will use this new certificate to establish trust with the vCenter server.

Conclusion

In this blog post, we have covered the process of replacing a self-signed Management Agent certificate in vRA7.6. We have obtained the Management Agent identifier and SSL thumbprint from the configuration file and executed the command to replace the certificate. Remember that everything is case sensitive, so make sure you enter the identifiers and thumbprints correctly.

If you are working with vRA7.6 and need to replace a self-signed Management Agent certificate, I hope this post has been helpful. Happy automating!

Working with Subscription Event Based vRO Workflows and ABX Actions in vRA8

As an IT professional, I have had to deal with my fair share of subscription event based vRO workflows and ABX actions. One of the frustrating aspects of working with these is that you often want to be able to develop in vRO using the vRA payload without having to constantly ask vRA to create a deployment just to push the payload downstream to vRO. In this blog post, I will discuss a recent approach that I have taken to overcome this challenge.

The Challenge

One of the challenges of working with subscription event based vRO workflows and ABX actions is that you want to be able to test and develop these workflows without having to constantly trigger vRA deployments. This can be time-consuming and can lead to a lot of unnecessary deployment activity. Additionally, if you are working on a large-scale vRO environment, the sheer number of deployments can become overwhelming.

The Approach

To overcome this challenge, I have been using a recent approach that involves triggering various vRA event subscriptions and storing the payload. This allows me to recall the payload and use it as much as I want to test and develop my vRO workflows and actions without having to touch vRA at all.

The Process

To use this approach, you will need to first download a package that includes three workflows, one action, and a configuration element with a path. Once you have imported the package into vRO, you can create an event subscription in vRA8 that will trigger the ‘Save vRA inputProperties’ workflow. When the event subscription executes, the input payload will be saved into the configuration element under a new attribute!

To use the saved configuration, you can use the included action, ‘LoadSavedInputPropertyDefinitions’ and pass its output into your workflow, mapping its output to your inputProperties payload. You can specify the project and the event that you want to use, as per the example in the included workflow ‘Simple Example Of Using Saved Data.’

Benefits

The benefits of using this approach are numerous. Firstly, it allows you to test and develop vRO workflows and actions without having to constantly trigger vRA deployments. This can save a significant amount of time and reduce the number of unnecessary deployments. Additionally, it allows you to use the vRA payload directly in your vRO workflows and actions, without having to modify the payload or create custom connectors.

Conclusion

In conclusion, using subscription event based vRO workflows and ABX actions can be a challenge, but there is a recent approach that can help overcome this challenge. By triggering various vRA event subscriptions and storing the payload, you can recall the payload and use it as much as you want to test and develop your vRO workflows and actions without having to touch vRA at all. This approach can save time, reduce the number of deployments, and allow you to use the vRA payload directly in your vRO workflows and actions.

Sending Emails from ABX Actions in vRA8

As a fan of the ABX functionality in vRA8, I have been wanting to accomplish sending an email from an ABX for a while now. While there are plenty of resources available online for sending emails using public providers like Gmail or Amazon’s Simple Email Service (SES), I wanted to find a way to send emails using my internal MS Exchange Server. This proved to be a bit more challenging, but with some late nights and experimentation with different Python libraries, I was able to achieve my goal. In this blog post, I will share the steps I took to send an email from an ABX in vRA8.

First, I created four action constants to hold sensitive information:

| Name | Value |

| — | — |

| smtpLoginUsername | administrator@automationpro.lan |

| smtpServer | 10.0.10.13 |

| smtpLoginPassword | ****** (redacted) |

| smtpSender | administrator@automationpro.lan |

Next, I added each of these action constants as inputs for the ABX action. To do this, I selected “Action Constant” in the Type dropdown menu.

Two dependencies are required for this action to work properly. The first dependency is the exchangelib library, which can be found on GitHub. It’s important to specify the version of exchangelib as later versions have a conflict within the ABX execution environment. I used version 1.4.0 for my tests.

The second dependency is the python-dotenv library, which allows you to load environment variables from a .env file. This is necessary because the smtpLoginPassword action constant contains sensitive information that should not be hardcoded in the ABX.

With these dependencies added, I set up an event subscription to trigger the action to execute. This can be done by selecting “Event Subscription” in the Type dropdown menu and specifying the appropriate event. For example, you could subscribe to the “Deployment Completed” event to send an email after a deployment is complete.

Of course, you can add other inputs to the ABX action to include useful information such as the deployment name or any other relevant details. This will allow you to send more informative emails and make the process more efficient.

While it may seem like overkill to use an ABX to send an email, there are several benefits to this approach. For one, you don’t have to rely on external email providers, which can be useful in certain situations. Additionally, using an internal Exchange Server allows you to leverage the security and reliability of your own email infrastructure.

In conclusion, sending emails from ABX actions in vRA8 is a bit more involved than using public providers, but it’s definitely possible. By following these steps and using the appropriate dependencies, you can send emails from your ABX actions without relying on external services.

As an IT professional, I have found myself in situations where I need to perform upgrades or maintenance on my infrastructure, but I am met with the frustrating obstacle of expired root passwords. This can be especially true when working in a lab environment, where changing the password frequently can become a tedious and time-consuming task. However, there is a way to negate this issue and avoid having to change your root password ever again.

To start, you will need to execute the following command to see the current configuration for the root account:

“`

cmk -s -p -c

“`

This will display the current configuration for the root account, including the expiration date of the password.

Next, you will need to execute the following command to set the password expiry period to be 9999 days in the future:

“`

cmk -s -p -c -e 9999

“`

This will set the password expiry period to 9999 days in the future, which is equivalent to never expiring.

Finally, you will need to execute the following command to set the minimum number of days between changes to 0:

“`

cmk -s -p -c -m 0

“`

This will ensure that the root password does not expire and cannot be changed for an extended period of time.

It is important to note that if you are running a cluster, you will need to perform these steps on every node individually. However, once completed, you will never have to change your root password again, saving you time and frustration in the long run.

In conclusion, this tutorial has shown how to negate the need for changing the root password ever again in Lifecycle Manager. By following these simple steps, you can ensure that your infrastructure is secure and easy to manage, without the burden of frequent password changes. So go ahead, take control of your infrastructure, and never let expired passwords hold you back again!