Property Sets

OneFuse Property Sets overview

Property Sets are typically grouped in one of two main functional areas:

  • Property Sets for modeling OneFuse Policies
    • Used for Template Previews in the OneFuse platform while building Policies with the Active Property Set.
      • Ability to validate the result of a Policy while building it, giving the user real-time feedback on exactly how the Policy will behave with a certain set of inputs.
  • Property Sets for Property Toolkit features
    • Properties get applied to the resource being provisioned as configuration. Each property in these Property Sets is used to drive the outcomes of the resource that we are building.
    • Some properties may be used to name the resource, determine the number of CPUs, or place a virtual machine in a particular cluster. Almost any aspect of the provisioned resource is capable of being influenced by these Property Sets.
    • Template both key:value of the property
    • Call other Property Sets within the parent Property Set

Managing Property Sets

Create a Property Set

  1. Select Templating > Property Set from the left navigation menu.
  2. Select the [+ Create] button from the Property Sets datatable.
  3. Fill out the Property Set form.
  4. Select Create.

Recommendations for Property Set names

We recommend establishing a naming standard for how you want to name your Property Sets. The standardized naming of Property Sets will facilitate easier organization and search of existing Property Sets, as well as, make it straightforward when calling Property Sets from an Upstream Provider.

Considerations:

  • Type of Property Set: Consider prefixing Property Sets with an identifier for template Property Sets or Property Toolkit (ptk) Property Sets. These are two very different use cases and can help differentiate Property Sets in the UI.
    • template_east_dev_apache
    • ptk_app_apache
  • Purpose of Property Set: This helps to further organize Property Sets based on the overarching purpose for the Property Set. For example, the Property Set could define how to deploy an application, or an OS.
    • ptk_app_apache, ptk_app_sql
    • ptk_os_windows2016, ptk_os_centos7
  • Property Set name typographical convention:
    • camelCase
    • all_lower_underscores

Update a Property Set

Update the Property Set to change the name or properties.

  1. Select Templating > Property Set from the left navigation menu.
  2. Find the Property Set to update and select the pencil icon button.
  3. Edit the information on the Property Set form.
  4. Select Update.

Delete a Property Set

  1. Select Templating > Property Set from the left navigation menu.
  2. Find the Property Set and select the trash can icon button.
  3. Confirm by selecting the [Delete] button.

Property Set form

Field Description
Property Set Name Enter a name for this Property Set.
Description Optional description for this Property Set.
Property Set Valid JSON format of a property stack.

Active Property Set

The Active Property Set enables users to select a specific Property Set to render the template preview results of templatable fields before executing a OneFuse Policy.

Initially, the Workspace will not have any Property Sets defined.

Get started

  1. Create a Property Set if none exist or when desired.

The first Property Set (alphabetical order ascending by name) will be selected by default.

Active Property Set panel with callouts 1 to 4 (opens full-size image in a new tab)

Number Description
1 Select the icon to open and close the Active Property Set
2 Select the desired Active Property Set from a list of existing Property Sets
3 View the Property Set properties
4 Select the button to open the Property Set in a new browser window tab

Templatable fields

All Templatable fields on forms, meaning the user can apply optional Templating to dynamically set the value of the field, is denoted by the code braces icon.

Templatable field with the code braces icon (opens full-size image in a new tab)

Refer to our Templating guide to learn more.

Template preview results

The Active Property Set will be used to render the template preview results for the particular field.

The user can select the eye icon to show the rendered template.

Template preview result of a templatable field (opens full-size image in a new tab)

Property Sets for Property Toolkit features

key:value of properties are templatable

Prior to OneFuse v1.4, Property Sets used to be called Static Property Sets since its properties could not be templated. It mainly served to model OneFuse Policies by enabling easy Template Previews and to pass static properties to Upstream Providers to use for resources.

Starting in OneFuse v1.4, both the key and value of a property is templatable and can be utilized to dynamically render properties and call other Property Sets.

Recursion

Templatable key:value within a Property Set can result in nested recursive renderings of other dynamic properties. By default, the max limit of recursive rendering is set to 3.

Duplicate key behavior

In the event of a rendered property key that already exists, it will overwrite the previous value with the latest rendered value.

{# Notice that the property key 'foo' exists in all but one Property Sets below #}

{# Child Property Set Properties for app_apache #}
{
 "foo": "Hello",
 "application": "apache",
 "nameApp": "apa"
}

{# Child Property Set Properties for loc_atl #}
{
  "foo": "Hello World",
  "location": "atlanta",
  "nameLoc": "atl"
}

{# Child Property Set Properties for env_prod #}
{
  "environment": "prod",
  "nameEnv": "prod"
}

{# Parent Property Set Properties #}
{
  "foo": "bar",
  "{{ Environment }}": "1FPS_Environment|env_{{Environment}}",
  "1FPS_001Application": "app_{{ Application }}",
  "1FPS_002Location": "loc_{{ Location }}"
}

{# Example templateProperties combined with parent Property Set #}
{
   "application": "apache",
   "location": "atl",
   "environment": "prod"
}

{# Resolved parent Property Set with templateProperties above #}
{
  "foo": "Hello World",
  "Environment": "prod",
  "Application": "apache",
  "Location": "atl",
  "prod": {
    "environment": "prod",
    "nameEnv": "p"
  },
  "application": "apache",
  "nameApp": "apa",
  "location": "atlanta",
  "nameLoc": "atl"
}
{# 'foo' is now 'Hello World' #}

Call Property Set(s) within a parent Property Set

The example below assumes at least one Property Set exists and the following properties are added to the “parent” Property Set.

Call a child Property Set and merge it into the parent Property Set:

Property Name Format Property Value Format
1FPS_<CustomID> Templatable. Name of the Property Set.

Replace <CustomID> with a unique, user-defined friendly label.

For example:

{# <CustomID> is 001Environment #}
{# Property Set name starts with 'propertyset_' #}
{# Property Set name will render 'Environment' variable that is passed in #}

"1FPS_001Environment": "propertyset_{{ Environment }}"

{# When Environment property is passed with a value (e.g. dev or test) it will call the Property Set: propertyset_dev #}

Call a child Property Set and merge its properties within a specific key of the parent Property Set:

Property Name Format Property Value Format
<Property Key Name> 1FPS_<CustomID>|<Child Property Set Name>
  • Replace <CustomID> with a unique, user-defined friendly label.
  • Replace <Child Property Set Name> with the name of the desired Property Set.

For example:

{# <Property Key Name> is EnvironmentProps #}
{# <CustomID> is 001Environment #}
{# Property Set name starts with 'propertyset_' #}
{# Property Set name will render 'Environment' variable that is passed in #}

"EnvironmentProps": "1FPS_Environment|propertyset_{{ Environment }}"

{# When Environment property is passed with a value (e.g. dev or test) it will call the Property Set: propertyset_dev #}

CustomID

CustomID refers to a user specified text string to identify and can set an order of precedence for execution when calling multiple Property Sets for the “parent” OneFuse Property Set.

Replace <CustomID> with a unique custom identifier:

  • Format is alphanumeric characters only A-Z, a-z, 0-9. No spaces, underscores, hyphens, nor special characters.
  • Must be unique across the entire Property Set properties stack.
Application
Environment
Location

Specify sorting with CustomID:

When executing multiple different OneFuse Module’s Policies in the same EBS State, prefix the <CustomID> with a numeric value (for example, 001, 002, etc).

The <CustomID> is sorted prior to executing the OneFuse module’s policies.

001Location
002Environment
003Application

Example parent Property Set

Example parent Property Set’s properties that call 2 child Policy Sets.

{
  "foo": "bar",
  "1FPS_001Environment": "propertyset_{{ Environment }}",
  "ApplicationProps": "1FPS_App|propertyset_{{ Application }}"
}

Override default settings via customer_settings.py

The following can be modified via the customer_settings.py file on the OneFuse appliance.

  1. SSH to the target OneFuse appliance

    • ssh as the root user and switch to root user with sudo su - and then run required commands.
  2. Go to the following directory

    cd /var/opt/cloudbolt/proserve/
    
  3. Add the following line to the customer_settings.py file

    # Override default prefix for calling Property Sets
    #Replace "1FPS_" with the desired prefix
    ONEFUSE_DYNAMIC_PROPERTY_SET_PREFIX = "1FPS_"
    
    # Override default max nested loop renders within Property Sets
    #Replace 3 with the desired max recursion limit
    ONEFUSE_DYNAMIC_PROPERTY_SET_RECURSION_LIMIT = 3
    
  4. Save the file


Property Sets for modeling OneFuse Policies

Create and use Property Sets for previewing Templates in OneFuse Policies.

Best practices

When creating Property Sets for Template Preview purposes on a OneFuse Policy, the easiest way to get started is to start with the properties required for each Policy that you are building. As you add additional OneFuse Policies and use cases to your environment, you can continue to build these Property Sets out to address the new use cases.

Examples

Property Sets for Naming Policy

I want to create a Naming Policy that asks for Location, Environment, and Application for my generated name. Several different combinations are shown in the table below. While you could create a Property Set for each of the possible combinations for the properties listed below, usually 2 to 3 Property Sets are suitable to test your OneFuse Policies.

Location Environment Application
east dev apache
west test sql

The result of two the combinations from above could look like the following:

Property Set: east_dev_apache

Property Set with name east_dev_apache and the following Properties:

{
  "nameLocation": "east",
  "nameEnv": "dev",
  "nameApp": "apache"
}
Property Set: west_test_sql

Property Set with name west_test_sql and the following Properties:

{
  "nameLocation": "west",
  "nameEnv": "test",
  "nameApp": "sql"
}
Template Preview Naming Policy

Switch between the east_dev_apache and west_test_sql as the Active Property Set when previewing template render for the Naming Template field on a OneFuse Naming Policy.

{{ nameLocation[0:1] | required('nameLocation is required') }}{{ nameEnv | required('nameEnv is required') }}{{ nameApp[0:2] | required('nameApp is required') }}{{ sequence.mySequenceName }}

{# Property Set: east_dev_apache Template Preview Result #}
edevap

{# Property Set: west_test_sql Template Preview Result #}
wtestsq

Create Property Sets from a Job

The easiest way to capture the exact state of a particular request would be to create a Property Set from a recently requested OneFuse Policy execution job for a resource.

  1. In the OneFuse UI, go to Jobs.
  2. Select the view button for the Job of interest.
  3. From the Resolved Properties tab, copy the entire templateProperties section to include the leading and trailing curly brackets.
  4. Go to Templating > Property Sets > [+ Create].
  5. Give the Property Set a name that describes what the data applies to.
  6. Paste the copied data from the Job in the Property Set field.

Property Sets for Upstream Providers

Create and use Property Sets for Upstream providers.

The following structure is recommended to house properties for multiple Upstream Providers in one Property Set. When referencing properties that are specific to a particular Upstream Provider, place those properties inside of Upstream Provider-specific sub-objects.

{
  // Properties defined at a Global Level
  "ansible":{ // Properties will be used for Ansible Module only (ignored by other Providers)
    // Properties
  },
  "cloudbolt_cmp":{ // Properties will be used for CloudBolt CMP only (ignored by other Providers)
    // Properties
  },
  "python":{ // Properties will be used for Python Module only (ignored by other Providers)
    // Properties
  },
  "vra8":{ // Properties will be used for vRA8 only (ignored by other Providers)
    // Properties
  },
  "vra7":{ // Properties will be used for vRA7 only (ignored by other Providers)
    // Properties
  },
  "terraform":{ // Properties will be used for Terraform only (ignored by other Providers)
    // Properties
  }
}