Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
The OneFuse Property Toolkit is the Swiss army knife of the OneFuse Platform
The OneFuse Property Toolkit is the Swiss army knife of the OneFuse Platform. It can be used in many different ways to assist you in meeting your automation needs. It can be used to simplify configurations, define business logic as configuration, build simple logic or tackle the most complex problems. In its simplest form its meta-data that can be used as a reference offering simple name value pairs that can be used as a reference for decision making. In its most powerful form it can contain logic, decision trees, platform abstractions, and much more.
It’s a blank canvas waiting to solve the needs of any organization. A common use for the Property Toolkit is to centrally define organizational business logic as configuration that can be used to standardize across different tools allowing you to centralize your business logic and maintain standards across the organization.
This article is intended to cover the basics of OneFuse Property Toolkit. I will cover much more advanced use cases in future articles, this one is intended to help you gain an understanding of its basic foundational uses.
Laying the foundation
If you are reading this you are most likely familiar with the concept of property groupings and the value that is provided by using them. Property Toolkit can be leveraged to provide basic groupings of properties allowing you to call upon them to access properties and values they hold. This can be done natively on most platforms however when used within the capabilities of a particular platform the data is restricted to that platform and would need to be duplicated for each platform you use.
This leads to drift. Values may be updated in one platform, but not in another causing organizations issues with maintaining standards, enforcing compliance, and maintaining security posture to name a few. Maintaining these in a centralized location reduces maintenance of the environment and helps maintain standards across your organization.
OneFuse Property Sets are what we use to create and maintain data used as part of the Property Toolkit. These property sets leverage standard JSON formatting giving you the power to determine how they should be structured.
Basic Property Set
Below is an example of a property set in its most basic form. A set of properties and values that can be consumed and used across platforms.
{
"nameEnv": "p",
"folderEnv": "PROD",
"ipamEnv": "prod",
"ouEnv": "PRD",
"location": "atl",
"dnsSuffix": "infoblox851.sovlabs.net",
"deployNameEnv": "Prod",
}Structured Property Set
Below is an example of a structured property set. Structuring gives some advantages over a flat basic property set that allow us to incorporate related properties using structure. In the below example I’m representing my standard for a linux deployment, CentOS7. I have two top level parameters that apply to all platforms for my environment familyOS & nameOS. You will notice three parent objects with children. Each one depicts a different platform that I have in my environment. vRA7, vRA8, and Terraform (TF).
Here I can define my environmental standards, but account for differences across the different platforms. In this case specific properties regarding how a template is consumed by each platform. If I need to make an update to my Linux standard template I can edit this one property set to make the change for all. New deployments will have the updated information across all the platforms.
Example: Standardizing vSphere Templates
{
"familyOS": "linux",
"nameOS": "l",
"OneFuse_VRA7_Props": {
"CloneFrom": "CentOS7",
"CloneSpec": "Linux"
},
"OneFuse_VRA8_Props": {
"image": "CentOS7",
"imageRef": "CentOS7",
"customizationSpec": "Linux"
},
"OneFuse_TF_Props": {
"template": "CentOS7"
}
}OneFuse Template Engine and Property Sets
OneFuse property sets support the use of the OneFuse template engine. This affords even more flexibility in standardizing your organizational logic in one place. Building on the previous nested example OneFuse can make it even easier to make updates to the template by leveraging the template engine as seen below.
Using this type of structure only one entry needs to change to impact the template used for all platforms. The parent properties seen in the below examples for vRA (OneFuse_VRA7_Props & OneFuse_VRA8_Props) are reserved properties leveraged by the OneFuse vRO package for vRealize Automation. It will automatically detect which vRA platform you are using and only pull in the appropriate properties for the version.
Example: Standardizing vSphere Templates
{
"familyOS": "linux",
"nameOS": "l",
"defaultTemplate": "CentOS7",
"OneFuse_VRA7_Props": {
"CloneFrom": "{{defaultTemplate}}",
"CloneSpec": "Linux"
},
"OneFuse_VRA8_Props": {
"image": "{{defaultTemplate}}",
"imageRef": "{{defaultTemplate}}",
"customizationSpec": "Linux"
},
"OneFuse_TF_Props": {
"template": "{{defaultTemplate}}"
}
}Below is another example that is used to standardize T-shirt sizing across platforms while using the template engine to make it easy to update. Simply update the info at the top of the group, and all platforms that have been accounted for will start using the new sizes for their deployments. No need to update vRA7, vRA8, Terraform plans, or other platforms.
Example: Standardizing T-Shirt Sizing
{
"size": "small",
"cpuCount": "1",
"memoryMB": "1024",
"memoryGB": "1",
"OneFuse_VRA7_Props": {
"VirtualMachine.CPU.Count": "{{cpuCount}}",
"VirtualMachine.Memory.Size": "{{memoryMB}}"
},
"OneFuse_VRA8_Props": {
"flavor": "{{size}}"
},
"OneFuse_TF_Props": {
"vcpu": "{{cpuCount}}",
"mem_size": "{{memoryGB}}"
}
}The concept of standardization goes well beyond the examples shown here. The same concept shown around standardizing templates and sizing above can be extended to tagging and other uses as well. It is also not limited to vSphere. Using the OneFuse Property Toolkit templates can be standardized across consumption platforms but also clouds. We can further nest and define what template should be used for vSphere, AWS, Azuze, GCP and others. This is also the case with sizing, and tagging.
Tagging is an area where I see many organizations struggle to ensure the appropriate tags are placed against the appropriate resources against all clouds. We will dig further into each of these use cases in future articles for each of them.
Nesting Property Sets
To make it even easier to maintain standards you can nest property groups inside one another. In the following example I have a property group that is used to define an application. Applications typically involve using an operating system. While you could define the operating system information within the application property set when you change templates you would need to update every application property set you have created.
This is made much easier by nesting the operating system group within the application group. Using this methodology when you make a change to a new template for an updated version of the OS, you simply update the OS group and all dependent applications will start using the new template as well. In the below example there is an entry for “OneFuse_SPS_OS” this is the property used to refer to a OneFuse Static Property Set.
The OneFuse-provided vRO package for vRealize Automation looks for anything that starts with “OneFuse_SPS_” to determine if the property defined relates to a OneFuse property set. The “OS” portion is user determined and can be anything you find to be appropriate that is unique. The value is the name of the property set in OneFuse.
{
"nameApp": "web",
"ipamApp": "web",
"OneFuse_SPS_OS": "sps_os_centos7",
"deployNameApp": "WORDPRESS",
"scriptPolicy": "wordpress"
}I hope this helps you see the possibilities of the OneFuse Property toolkit and it’s Static Property Sets. In future articles we will dive into specific use cases and look at how using the OneFuse Property Toolkit can help you standardize your business logic as simple, manageable configuration consumable by any platform.