Share This:

This post shares some thoughts on how Tagging works in CLM 3.1.

 

In this post, I’ll describe how to use Tagging to determine the placement of provisioned, user-requested services within BMC Cloud Lifecycle Management (CLM) version 3.1.

I’ll cover how CLM uses tags, the difference between tags for placement vs. tags for options, and give an end-to-end example of how to use tagging effectively.

 

BMC Cloud Lifecycle Management (CLM) uses Tags for many features, including Placement and Options.

 

Placement

When provisioning, CLM matches blueprint tags and tenant tags with resources tags, according to Service Governor Policies, to determine where to provision.

 

Options

Tags can be used to specify to what part of the blueprint the option applies.

 

Creating tag groups and tags:

When used in policies, tags and tag groups help to determine the placement of provisioned, user-requested services within the cloud.The following video uses an analogy to explain tags and how BMC Cloud Lifecycle Management uses tags to determine placement when provisioning services:

 

CLM Tags and Tagging

 

Refer Creating tag groups and tags [requires support login] for more information on CLM tags and Tagging.

 

Tags and Placement

There are many players/places which can be tagged to determine where to provision which includes following:

 

Tags in the Blueprint

Tags on Four Different Blueprint Elements Are Used For Placement:

  • Service Definition (also referred to as the Functional Model/Component)
  • Service Deployment Definition (also referred to as the Deployment Model)
  • Resource Set
  • Compute Resources Tab

 

There are other Blueprint Elements which can also be tagged

  • These tags are used in conjunction with Options

 

Tags on Resources and Tenants

Here is the list of Resources which can be tagged:

  • Network Containers/Networks
  • Compute Pools (including Virtual Disk Repository Pools)

Tenants can also be tagged.

 

Tag Group references in Service Governor Policy

The Service Governor defines policies that determine how cloud end user requests get mapped   to underlying resources.

 

Here is the list of resources for which you can define Policies:

  • Network Containers
  • Compute Pools
  • Virtual Disk Repository Pools
  • Networks

 

Refer Policy Management Overview [requires support login] for more information [requires support login]

 

Use following information to configure each policy:

  • Specifies a Tag Source: Blueprint or Tenant
  • Specifies a Tag Group
  • Multiples may be And’d or Or’d together

 

Below screenshot can be referred to configure each policy:

Service Governor.png

 

Based on the above configuration, the Tags in the Tag Group in the Tag Source(s) are matched to Tags in that Tag Group on the Specified Object.

 

Please refer “Features” section in Service Governor Overview [requires support login] for detailed information on “Match All” and “Match Any” options.

 

Selection of Blueprint Tags

Blueprint Tags are Evaluated “Bottoms Up” (where Service Blueprint Definition is at the top and Compute Resource at the bottom in the hierarchy).

 

Refer Service blueprint tag selections in policies [requires support login]

 

What Tags are used depends on what is being selected. Here is the list of resources and the hierarchy to select Tag Group and Tags, to determine the resources, from Service Blueprint:

 

Network Container

  • Service Deployment Definition
  • Service Definition

 

Compute Pool

  • Compute Resources Tab
  • Resource Set
  • Service Deployment Definition
  • Service Definition

 

Virtual Repository Pool

  • Compute Resources Tab
  • Resource Set
  • Service Deployment Definition
  • Service Definition

 

BMC Cloud Lifecycle Management (CLM) Tag and Tagging examples:

 

Refer Adding and Editing Policies for more information on terminologies used in following examples.

 

Blueprint Tag Example 1: Network Containers:

 

In following example, In the Policy, Tag Source is "Service Blueprint" so the Tag Group defined in Policy will look for a Tag Group match only in Service Blueprint based on the hierarchy. Matched Tag Group and it's associate Tags will be used to  look for a selected Tag Group and Tag match in all qualified Network Containers:

Ex1.png

 

Blueprint Tag Example 2: Compute Pools

 

In following example, In the Policy, Tag Source is "Service Blueprint" so the Tag Group defined in Policy will look for a Tag Group match only in Service Blueprint based on the hierarchy. Matched Tag Group and it's associate Tags will be used to  look for a selected Tag Group and Tag match in all qualified Compute Pools:

Ex2.png

 

Blueprint Tag Example 3: More Compute Pools

 

Explanation is same as in previous example

 

Ex3.png

 

Blueprint Tag Example 4: Storage

 

Explanation is same as in previous example

 

Ex4.png

 

Blueprint Tag Example 5: What Happens?

 

In following example: All of the condition listed in this policy must be met before the policy will be in effect (Match All).

 

In the Policy, Tag Source is "Service Blueprint" so the Tag Group defined in Policy will look for a Tag Group match only in Service Blueprint based on the hierarchy. Matched Tag Group and it's associate Tags will be used to  look for a selected Tag Group and Tag match in all qualified Network Containers:

 

Tag Group "AR-NC" and "AR-ComputePlacement" has a match in Service Blueprint (AR-NC:MNetwork and AR-ComputerPlacement:Gold) but none of the available Compute Pools has both the Tag Group/Tag matched, which triggers Placement failures:

 

Ex5.png

Blueprint Tag Example 6:

 

In following example: If any of the conditions listed in this policy are met, the policy will be in effect (Match Any).

 

Tag Group "AR-NC" and "AR-ComputePlacement" has a match in Service Blueprint (AR-NC:MNetwork and AR-ComputerPlacement:Gold) but based on the Policy condition and criteria (Match Any), two Compute Pools will be qualified and an advisor will be called for random selection:

 

Ex6.png

 

Combination of Options and Tags

 

The primary purpose of configuring Option Choices is that the cloud administrator allows end users to modify the services they are requesting to meet their specifications.

 

Blueprint is stored internally as text files (json) and the Option Choice Blueprint Configuration Editor generates text for each option choices.

Early in the provisioning process, the Service Offering blueprint and the option choice(s) text are merged to produce a new blueprint for that provisioning activity.

 

Refer Options overview for more information on options [requires support login]

 

An option can add software to a functional component or increase the number of CPUs in a resource set but it’s interesting to which functional component or which resource set and how.

An option choice can identify the specific blueprint element by name or by tag but there are pros and cons of each method of resource set identification.

In following example, all resource set are getting identify by “AR-Deployment Sizing” Tag Group and “2vCPUx2GBRAM” Tag. You can also identify resource set by its specific name. Select “by Name” radio button:

 

Ex7.png

Since options can be shared across Service Offerings, identifying by name requires strong naming standardization and this method can increase the count of option choices. Standardized use of tags is likely to be easier to implement and one option choice can be used to identify multiple resource set.

 

Options can be used to set Tags that are used for Placement on the fly. Tags can be used to identify the Blueprint element upon which to set the Placement Tags.

 

In following example, “AR-ComputePlacement” Tag Group and “All” Tag is identifying the resource set upon which Placement Tag Group and Tags is being set:

 

Ex8.png

 

Refer Option Choices available when extending service blueprints

 

Tagging recommendations and examples

 

Refer Tagging recommendations and examples [requires support login]

 

I have created Knowledge Articles which covers step by steps configuration details on various use cases around Tagging and options.

 

Refer KA403914 which covers basic configuration of an Option, Option Choices and Tagging to select a Network Container.
[requires support login]

Refer KA403915 which covers basic configuration of an Option, Option Choices and Tagging to select a Compute Pool.
[requires support login]

Refer KA403917 which covers basic configuration of an Option, Option Choices and Tagging to select a Network.
[requires support login]

 

In this post, I covered basic configuration points and suggestions for implementing Options and Tagging to determine resources for placement in BMC Cloud Lifecycle Management.

 

I hope this article helps to understand good ways to use tags in BMC Cloud Lifecycle Management (CLM), please share you experiences or feedback on these features with comments below.