Creating a OneFuse Naming Policy

OneFuse Naming Features

The following list is not all inclusive.

• Define multiple naming policies
• Use across vRA7, vRA8, vRA Cloud, Terraform, Cloudbolt CMP, and API
• Support for Decimal, Hexadecimal, Octal, and Pattern Sequences
• Ability to define zero or more sequences per naming policy
• Ability to re-use sequence values or not to re-use sequence values
• Define custom unique keys for tracking sequences
• Define naming validators to ensure uniqueness across vRA7, vRA8, and DNS
• Supports Jinja2 templating language with additional OneFuse-specific filters
• Names are maintained as trackable objects providing visibility

The above features are important because they provide capabilities that most don’t know they need until they run into a problem and it’s too late.  Take validation for instance.  This is extremely important in an enterprise environment.  The ability to validate the uniqueness of the generated name before it gets assigned and causes a conflict or an outage is critical.

I have discussed the importance of this with many organizations who at first glance were convinced the default support for naming within vRA8 was enough to support their needs. I certainly understand why some would believe that. It’s far better than naming prefixes that are in vRA7, but where does it break down? Below is a list of some things to consider when determining if vRA8 naming is enough for your organization.

vRA Naming Considerations

1. Will you be using the same naming standard across projects within vRA8? Will you have multiple tenants or instances of vRA8? Do you have multiple projects or organizations in vRA Cloud? Do you want to use vRA8 and vRA Cloud simultaneously? If so, this can possibly cause challenges. When using the same naming convention across projects/tenants/orgs/instances where they sequence by project may cause overlaps in names and service conflicts.
2. If you have different organizations or are still using vRA7 along with vRA8 you now need to maintain your naming standard and sequences independently across them which can lead to naming overlaps and conflicts.
3. There is no validation included within vRA which limits your ability to determine if the name is indeed unique to your environment.
4. Do you need to name other vRA canvas items? Items such as public cloud resources, e.g. S3 buckets, Azure DNS records, etc. Naming standards within vRA can only name machines.
5. Do you need to generate unique names or name resources within vRO workflows or ABX actions? Naming standards within vRA can only name machines within Cloud Assembly.
6. Naming standards within vRA can only be utilized within vRA.

While there are a lot more reasons to leverage the OneFuse Naming module they are more solution based and will be covered in other use case specific articles. Next, we will walk through setting up a basic naming policy that will teach you the basics of configuring and consuming naming from within vRA.

Naming Validators

Naming validators are what you will use to determine if a name already exists in your environment.

The ability to validate the uniqueness of the generated name before it gets assigned and causes a conflict or an outage is critical.

Prerequisites

• Module Endpoint for Validator type

In order to create the Naming Validator, you will need an endpoint configured for the specific validator type you are wanting to use. In my previous article “Configuring the OneFuse Appliance”, I walk through creating a DNS endpoint that I will be using during the creation of the DNS Naming Validator below.

Creating a Naming Validator

For this example I’m going to configure a DNS naming validator.

1. Select Naming from the Home screen.
2. Select “Create” under “Naming Validators”.
3. On the “Create a Naming Validator” screen, give your validator a name, a description, choose the appropriate validator type (DNS in this example), and select the appropriate endpoint that was previously created and select Create.
4. You may repeat these steps to create as many validators as you’d like for DNS, vRA7, and/or vRA8.

Naming Sequences

Naming sequences are how you make your generated names unique.  There are a number of settings within the sequence definition that warrant some further explanation.

Sequence Type – There are four supported sequence types:

• Decimal – The most commonly used.
• Hexadecimal – Allows you to generate more sequences per name variant.
• Octal – A base-8 numbering format..
• Pattern – Allows you to determine a specific pattern to be used, including one or more of the following: A/B, binary, mixed static/dynamic text, and all other numeric sequence types.

Reuse Sequence Values – You have the option to enable or disable the reuse of sequence values.

• Disabled – Get the next available sequence, starting from the last number used.
• Enabled – Reuse a previous sequence that is no longer in use, starting from initial value

If you enable Reuse Sequence Values, it does not go to the end of the sequence before it reuses a previously used value – it will look from the beginning for the next available number that is not in use. Keep in mind, sequence numbers resulting in conflicts detected by validators will automatically be skipped, making reuse a safe operation.

Maximum Length – The length you want the sequence to be.

Example: A Decimal Sequence with a Maximum Value of 3 would cover 001 – 999.

Padding Character – Typically this is 0, but could be any character – for the first number in a 3-digit decimal sequence with “0” as a padding character would yield “001” – with “A” as a padding character instead that would yield “AA1”.

Initial Value – Where should name generation begin? This allows you to set a starting point so you don’t overlap with existing names that may have been generated by another means. If you are at sequence 349 you can begin at 350 and pick up generating names where there is no overlap. Of course, validation will catch the used names so you could start at 001 and on the first request it will increment until it finds the first available combination in the sequence.

Unique Key – In most cases the unique key will be the same as your naming standard you intend to use the Sequence with, but this does not have to be the case and it is in an optional field.  This field should capture all the variables that you want to track sequencing independently for.

In my example, I will be using the below naming template:

{{nameGroup}}{{nameLocation}}{{nameEnv}}{{nameOS}}{{nameApp}}

I will also be using this as my unique key for my Sequence. In this event, it will look at the name generated from these inputs to determine when unique variants are created and sequence them each independently of one another. For example:

ITATLPRODWINDB could be a generated name and would get its own sequence starting at 001. OPSATLDEVLINWEB could be another generated name that would also get its own sequence starting at 001.

If I had no Unique Key, the sequence would not differentiate unique name combinations and it would sequence across them. This might look like ITATLPRODWINDB001 and OPSATLDEVLINWEB002.

You can also generate a unique key that contains only parts of the generated names as opposed to the entire template. For example:

{{nameGroup}}{{nameLocation}}{{nameEnv}}

This would allow you to sequence only the specific dynamic parts of the generated name versus the name as a whole.

Creating a Naming Sequence

1. From the Home screen select “Naming”.
2. Select “Create” under Naming Sequences.
3. On the Create a Naming Sequence screen, fill in the appropriate information as described above but do not select create just yet.
4. You may have noticed there is a {} icon next to the Unique Key field. You will see this throughout OneFuse and it is a very helpful feature. The {} denote fields that can use the OneFuse Template Engine (based on Jinja2). When we input {{NameGroup}} we are creating a variable or an input into the name or in this case the Unique Key.

   OneFuse has a built in mechanism that allows you to test the template language that you put in to determine if it’s going to give you the intended result. In my previous article “Configuring the OneFuse Appliance” we created a Static Property Set for use in the interface. With that assigned we can see what the output would be if those were the inputs past in as part of a request. To do this we need to select the eye icon in the right corner of the Unique Field. You can also see which Static Property Set is assigned and switch between different sets in the lower right corner by selecting the circle that contains {...}

   
5. When you are satisfied select Create.

Naming Policies

Naming Policies are where it all comes together. Here, you will define your naming template, you will assign your sequence you want to utilize, and you will define what validators you would like to use to validate names generated by this policy.

Prerequisites

• One or more Naming Sequences (optional)
• One or more Naming Validators (optional)
• Your Naming Standard you would like to use

Creating a Naming Policy

1. From the OneFuse Home Page select Naming.
2. Select Create under Naming Policies.
3. We then need to fill out the following values on the “Create a Naming Policy” page.
   
   Policy Name – give your policy a name. This will be used when you want to ask OneFuse for a name.
   
   Naming Sequence – Select the Naming Sequence that was created in the previous section.
   
   Naming Template – This is what is going to create your name based on the inputs provided to OneFuse. In this example I will be using the same template that I used for my Unique Key in the previous steps.

   {{nameGroup}}{{nameLocation}}{{nameEnv}}{{nameOS}}{{nameApp}}

   
   We however, need to add the sequence to the template so OneFuse knows where to place the sequence. Most commonly it’s placed at the end, however you can place it wherever you like within the name. You can also have more than one sequence within the name if you have the need. We add the sequence by defining it like so {{sequence.sequenceName}} as in the example below.

   {{nameGroup}}{{nameLocation}}{{nameEnv}}{{nameOS}}{{nameApp}}{{sequence.default}}

   
   Naming Validators – Select which validators you would like assigned to this policy.
   
   DNS Suffix – Specify the optional DNS Suffix you would like to associate with this name. This will be used by the DNS validator to validate the name against the specified DNS Suffix. Notice this field has the {} so we can use template language here if we like.
   
4. Next, validate your Naming Template and your DNS Suffix if it is templated to make sure you are getting the results you desire and then select Create when finished.