Share This:

Last time, we looked at how tagging works in BMC Cloud Lifecycle Management 3.1

 

In this Post, I will share some thoughts on how Service Governor Policies help determine/selecting underlying resources during “Service Offering instance” provisioning in BMC Cloud Lifecycle Management (CLM) 3.1.

 

The Service Governor defines policies that determine how cloud end user requests get mapped to underlying resources. Policies specify the automatic selection of compute, network, and storage pools during provisioning.

 

When you apply policies to a service blueprint and then provision a service instance based on that blueprint, tag matching dictates which resources are used for the service instance.

 

Note: You can also create policies that maps "Tenant" to resources. In following post, I will take an example of applying policies to a "Service Blueprint".

 

Refer Policy Management Overview for more information.

 

There are four out-of-the-box policies which help select underlying resources for Placement. Here are the list of Policies and their purpose:

 

Policy Type
Purpose
Network containerControls which network container a service instance is provisioned within. This is useful when a tenant has more than one network container available.
NetworkControls the placement of network interfaces when provisioning a service instance. Network policies are required when using tags to match network interfaces in the service blueprint to networks in the network container.
Compute poolControls which resource pools are used when provisioning a service instance
Virtual disk repositoryControls what storage is available on a virtual disk repository pool when provisioning a service instance.

 

The network container policy is evaluated before any other policies and if you have “network” policy configured then network policies are considered only for networks that are included in the selected network container.

 

Similarly, compute pool policies are considered only for compute pools that are mapped to the network container that is picked during network container policy evaluation.

 

Tags assigned to networks match network interfaces in the service blueprint to networks in the network container.

 

Each Policy has an xml, covers its logic to select resources for placement.

 

Here is the sample, out of the box, xml of “Compute Pool” policy type:

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Policy RulesCombinatorAlgorithm="PermitOverrides" PolicyVersion="1.0" PolicyType="selectStaticPools" LifecycleStage="production" PolicyId="csm placement policy staticpool 1" Category="PLACEMENT" Id="11111111-1111-1111-1111-111111111113" xmlns:ns2="urn:bmc:policies:common" xmlns="urn:bmc:policies">

    <Description>csm placement policy staticpool 1</Description>

    <Rule RuleId="csm placement policy staticpool 1 Rule 1.1" Effect="Permit">

        <Description>csm placement policy staticpool 1 Rule 1.1</Description>

        <Variables>

            <Variable Direction="out" DataType="list" VariableId="GUID">

                <ns2:List DataType="list"/>

            </Variable>

        </Variables>

        <Target>

            <Subjects Combinator="or">

                <AnySubject/>

            </Subjects>

            <Resources Combinator="and">

                <Resource ResourceType="StaticPool" ResourceId="StaticPool">

                    <IfTrue>

                        <VariableSet VariableId="GUID">

                            <AttributeSelector Id="StaticPool" DataType="string" AttributeId="StaticPool_guid"/>

                        </VariableSet>

                    </IfTrue>

                </Resource>

            </Resources>

            <Actions>

                <Action>

                    <Function FunctionType="simple" NumArgs="2" FunctionId="string-equals">

                        <AttributeValue DataType="string">

                            <Content>selectStaticPools</Content>

                        </AttributeValue>

                        <AttributeSelector DataType="string" AttributeId="actionId"/>

                    </Function>

                </Action>

            </Actions>

        </Target>

        <Condition/>

        <Output OutputType="auto"/>

    </Rule>

</Policy>

 

Based on above content, all static pools, associated to the selected Network Container, will be qualified and a random selection will be called to select one.

 

Screenshot of the configured Policy in “Service Governor” workspace:

Blog-3.png

As soon as you configure this Policy, with Tag Source and Tag Group, in “Service Governor” workspace, the following contents/logic is added to the existing out of the box Policy xml:

 

<Resource ResourceId="Blueprint" ResourceType="Blueprint"/>

                <Resource ResourceId="StaticPool" ResourceType="StaticPool">

                    <Function FunctionId="not-exists" NumArgs="2" FunctionType="simple">

                        <Function FunctionId="intersection" NumArgs="2" FunctionType="simple">

                            <Function FunctionId="filter" NumArgs="2" FunctionType="simple">

                                <AttributeValue DataType="string">

                                    <Content>^AR-ComputePlacement\..*</Content>

                                </AttributeValue>

                                <AttributeSelector AttributeId="Blueprint_tags_label" DataType="list" Id="Blueprint"/>

                            </Function>

                            <AttributeSelector AttributeId="StaticPool_tags_label" DataType="list"/>

                        </Function>

                        <AttributeValue DataType="list">

                            <ns2:List DataType="string"/>

                        </AttributeValue>

                    </Function>

                    <IfTrue>

                        <VariableSet VariableId="GUID">

 

The areas of interest in the above snippet are “Content”, “AttributeSelector” and “FunctionId” as those are the attributes which help in determining the underlying resource for placement.

 

All option/option choices parse in early stage of the SOI (Service Offering Instance) provisioning flow and Tag Groups/Tags are added to Service Blueprint if your Option Choices are configured for it.

 

The Service Deployment Definition gets update after parsing of selected Option/Option choices and a final Service Deployment Definition, to be provisioned, gets build.

 

The final Service Deployment Definition keeps track of these Tag Group/Tag which refer in later stage during Policy evaluation.

 

Based on the logic, all Tag Groups/Tags, from “Service Blueprint” are filtered out by the Tag Group configured in the “Service Governor” of the respective Policy, followed by the Intersection function to select the resource for Placement.

 

Example of Function:

{

AttributeValue{value=^AR-ComputePlacement\..*, type=STRING}

AttributeSelector{typeId=Blueprint, attribute='Blueprint_tags_label'}

AttributeSelector{typeId=ID_ENVELOPE, attribute='StaticPool_tags_label'}

AttributeValue{value=com.bmc.policy.types.common.ListDataTypesize : 0, type=LIST}

 

}

Here is an example of an actual logic which takes place:

[

('Blueprint.Blueprint_tags_label' type-attribute-selector 'NetworkType.All,AR-Deployment Sizing.4vCPUx6GBRAM,AR-NC.MNetwork,AR-Storage.1 GB,AR-ComputePlacement.Gold,') = true

('^AR-ComputePlacement\..*' filter 'NetworkType.All,AR-Deployment Sizing.4vCPUx6GBRAM,AR-NC.MNetwork,AR-Storage.1 GB,AR-ComputePlacement.Gold,') = true

('ID_ENVELOPE.StaticPool_tags_label' type-attribute-selector 'AR-ComputePlacement.Bronze') = true

('AR-ComputePlacement.Gold,' intersection 'AR-ComputePlacement.Bronze,') = true

('' not-exists '') = false

]

 

The Tag Group “AR-ComputePlacement”, as configured in Service Governor for “Compute Pool” Policy, filters Tag Group, available in “Service Blueprint” and lists all Tags associated to Tag Group-“AR-ComputePlacement”.

 

In this example, 'AR-ComputePlacement.Gold” is the filtered Tag Group/Tag from Service Blueprint.

 

An “Intersection” function use for each Tag Groups/Tags from qualified Compute Pool’s, with filtered Tag Group/tag in Service Blueprint,  followed by “not-exists” function “to identify the final resource for Placement.

 

Example:

[

('Blueprint.Blueprint_tags_label' type-attribute-selector 'NetworkType.All,AR-Deployment Sizing.4vCPUx6GBRAM,AR-NC.MNetwork,AR-Storage.1 GB,AR-ComputePlacement.Gold,') = true

('^AR-ComputePlacement\..*' filter 'NetworkType.All,AR-Deployment Sizing.4vCPUx6GBRAM,AR-NC.MNetwork,AR-Storage.1 GB,AR-ComputePlacement.Gold,') = true

('ID_ENVELOPE.StaticPool_tags_label' type-attribute-selector 'AR-ComputePlacement.Gold') = true

('AR-ComputePlacement.Gold,' intersection 'AR-ComputePlacement.Gold,') = true

('AR-ComputePlacement.Gold,' not-exists '') = true

]

 

I hope this article helps to understand on how Polices evaluation works in BMC Cloud Lifecycle Management (CLM) 3.1, please share you experiences or feedback on these features with comments below.