Skip navigation
1 2 Previous Next

Cloud Lifecycle Mgmt

16 Posts authored by: Abhishek Rai Employee
Share This:

Usage Scenarios

 

This video demonstrates the implementation and usage of 'transfer Ownership" feature in new My Cloud Web Service Portal, introduced in BMC Cloud Lifecycle Management 4.5. Refer "new My Cloud Service Portal" to understand other features introduced in this new console.

 

Using this feature, if the cloud user to whom a service offering instance is assigned to is no longer in the same role or in the same organization, a cloud administrator or tenant administrator can transfer the ownership of the service offering instance to another cloud user.

 

 

More Like this

 

You can find more videos like this on BMC CLM How-to Videos Catalog

 

Products and Versions

 

This video was made with the following products and versions:

 

     BMC Cloud Lifecycle Management 4.5

Share This:

Usage Scenarios


This video demonstrates the features of new My Cloud Services Console, which is one of the major enhancement in BMC Cloud Lifecycle Management 4.5.

 

BMC Cloud Lifecycle Management 4.5 introduces a streamlined My Cloud Services Console for end users. The new console provides easier access to the catalog of services available, makes options more intuitive to select, and allows multiple services to be requested at one time through the cart.


 

More like this

You can find more videos like this on BMC CLM How-to Videos Catalog

 

Products and Versions

      This video was made with the following products and versions:

          BMC Cloud Lifecycle Management 4.5

Share This:

In this post, I will describe the concepts and importance of “Share Services” feature in BMC Cloud Lifecycle Management. By taking a closer look at how this functionality works, we can understand the behavior observed in the application at a deeper level, which will help you troubleshoot any issue observed during implementation.


Until BMC Cloud Lifecycle Management 4.0, End users are not permitted to perform control or management operations on SOIs they do not own, and the system does not support granting an end-user such permissions.


From BMC CLM 4.x onwards, Cloud user (TA/CA/end user) can share a SOI with other CLM users and groups of his/her organization using any of the following:


Using operator action “Share SOI” for the existing SOI – Same action can be used to edit/remove the list of shared users/groups.


1.png


Once the SOI is shared, only Cloud Admin/Tenant Admin/SOI owner can revoke/edit the list of shared users/groups.


The end users with whom SOI is shared have full access similar to the SOI owner. The only thing shared end users are not being able to do is extend sharing to other users.


Following table illustrates the changes performed on Configuration Item (CI) when we share the Service Offering Instance:


 

Operation
RoleExisting OwnerData in CMDBRowLevelSecurityOwner Name Field
Share ServiceCA/TA/EUTenant Admin or End UserWe retain existing permission + 'new user id'No Changes

 

Following example will help you understand the changes in "CMDBRowLevelSecurity" field:


Before Sharing SOI:


2.png


After Sharing SOI with user 'arp_eu1':


3.png


Sharing Services creates a Relation between Service Offering Instance and BMC_Person only for the shared users.


4.png


Shared example can help you to troubleshoot the issue if an user, to whom you have shared the services, do not see the services to manage.


Following are the logic/validations while sharing the services (SOI):


1: Only Cloud Admin/Tenant Admin/SOI owner can share/revoke/edit the list of shared users.


2: The users with whom SOI is to be shared exists in DB and are all Cloud users (Cloud Admin/Cloud Org

Admin/Cloud End User). This user list can be empty. This will remove the sharing the SOI with all existing shared users.


Here is how we fetch the privileges and other information of an user with whom you share the SOI.


Snippet from CSM.log:


24 Feb 2015 12:11:15,962 [DEBUG] WLM - [Thread=80d935ba-0723-42a3-a332-efba5846217d::614b4467-f3cc-4bae-bba5-61b6b9612ef3::60037226-5b4a-421c-a2a7-2656036cc1bc(169)] [Class=ServiceOfferingInstanceShare:getUserFromDB] - t1cloudenduser2 User object from DB for -{

  "cloudClass" : "com.bmc.cloud.model.beans.User",

  "firstName" : "Cloud",

  "guid" : "AGHAA5V0H4FYPANEC68NHDG9S6APDE",

  "lastName" : "EndUser2-T1",

  "name" : "t1cloudenduser2",

  "organization" : [ "/organization/AGHAA5V0H4FYPANEANY5YTGVSWZGMP" ],

  "userName" : "t1cloudenduser2",

  "userPrivileges" : [ "/privilege/1500000001", "/privilege/20601", "/privilege/1000000009", "/privilege/20600", "/privilege/20000" ]

}

 

In above example, privileges are the "Group IDs" in Group form.

 

3: The user's organization is same as SOI's organization.

 

4: Filtering of all admins(CA/TA) from the user list. Since the SOI is already accessible for admins,

these will be excluded from the user list if any exists.


For example: Here is the error you receive when you share SOI with Cloud Org Admin:


24 Feb 2015 12:11:15,963 [ERROR] WLM - [Thread=80d935ba-0723-42a3-a332-efba5846217d::614b4467-f3cc-4bae-bba5-61b6b9612ef3::60037226-5b4a-421c-a2a7-2656036cc1bc(169)] [Class=ServiceOfferingInstanceShare:validateUser] - The users [[t1cloudenduser2]] already has access to Service Offering instance AR-RHEL-x86_64-ROD-version1-27

 

5: Update sharing of SOI and related CIs. This will append the user list to the existing CMDBRowlevelSecurity and will add the relation of SOI and BMC_Persons for the list of users with whom the SOI is shared.

 

Sharing can be done for all SOI states except Decommissioning, starting, stopping etc. It's only allow if the states are Running, Stopped & Installed.


CMDBRowlevelSecurity and BMC_Person Relationshsip with SOI will be updated for most of the following cloud classes at different layers:


Cloud Class

ServiceOfferingInstance

FunctionalComponent

FunctionalComponentConnection

ResourceNetworkPath

ResourceSet

LoadBalancerPool

LogicalCommunicationPath

ServerNetworkInterface

ComputeContainer

IPAddress

LocalDisk

OperatingSystem

BlockDevice

Filesystem

ApplicationSoftware

PhysicalServer

VirtualGuest

LBPoolEntry

 

Other References:

 

A new form "CMF:SYS-Access Permission Grps" has been introduced to support "Share Service" feature and has following descriptions:

 

5.png

1: This is an intermediate form introduce to generate the Group ID dynamically.

 

2: The group id range generated by this form for ‘Tenant Admin Group’ would be between 1500000000 to 1599999999

 

3: This form is used by ‘Migration Script’ and ‘Tenant Management’ UI to generate the ‘Tenant Admin’ group for on-boarded Tenants.

 

This group would then be used for assignment of the users created with ‘Cloud Organization Admin’ permission.

 

4: The Group Name and Group ID are auto generate by this form.

 

Following two filter are modified on the “BMC.CORE:BMC_BaseElement” form.


CMF:BAB:UpdateGroupList_Tenant_560

CMF:BAB:UpdateGroupList_Tenant_550

 

Description:

 

Above filters fetch the ‘Tenant Admin’ group from the “CMF:SYS-Access Permission Grps” form and update the CMDB Row level security field with the ‘Tenant Group ID’ for the respective ‘Tenant’ the CI’s belong to.


Refer Sharing services with other users


I hope this information is useful to understand this feature and troubleshoot any issues, if observe, on your own.


You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Visit CLM Blogs. You can share the links with others if you find these useful.

 

Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

Share This:

ContractLine configuration items hold key information and bridge Tenant’s contract with ServiceOffering, ServiceOfferingInstance, Option/OptionChoices and Price.

 

As a mandatory configuration item, missing Contractline records in the golden dataset (BMC.ASSET) can impact chargeback reports and Transactional Requestable Offering/Post Deploy Action.


Reconciliation, DSO and environment specific issues can be the major reasons of these missing relationships.


In this post, I will share steps to fix missing ContractLine relationships for ServiceOfferingInstance, ServiceOffering and Option/OptionChoices.


In my previous post on Insights of Contract and ContractLine, I covered various configuration items. Missing one of them will not display ServiceOffering name and Service Requests in details pane on Service Instances-Services tab.

 

16.png

 

Creating a missing relationship between ServiceOfferingInstance and BusinessService:


Open BMC_ServiceOfferingInstance form at Cloud AR/DB and check if BMC_BusinessServices and BMC_ContractLine relationships are missing. Copy the Instance Id of the ServiceOfferingInstance to create this missing relationships


17.png


Click “View Relationships” and from "Manage Relationships" window, click on "Namespace" drop down menu and select "BMC.CORE" and "BMC_Dependency" from "Relationship Class” and click on “create” button.


A new window will pop up. Update the Name field value to "SERVICEDELIVEREDBY" and select "BMC.ASSET" as a DatasetId.


In the "Select Destination" section, input the respective "Service Catalog" InstanceId for "Destination.InstanceId" field.


To know the Service Catalog Instance Id, open the "BMC_BusinessService" form and copy the "InstanceId" of a respective ServiceCatalog which was used to provision a VM (virtual machine)

 

18.png

 

Once configured, click on Save button. This will create a relationship between ServiceOfferingInstance and BusinessService.


Here is the list of possible relationships with BMC_Contractline configuration item:

 

19.png

 

Open "BMC_ContractLine" form and switch to "Custom 2" tab. Search the Contract Line by respective "Service RequestId". In case you do not know ServiceRequestId then switch to "Specifications" tab and search the contract line by "StartDate" of a SOI (service offering instance).

 

StartDate is the "ProvisionedDate" of a SOI which can be collected from details pane in Service Instances-Services tab on Cloud Portal.

 

Following steps will help you identify the ServiceRequest number if you do not know “ProvisionedDate” either.

Open ServiceRequests (SRM:Request) form at Enterprise AR in case there are two AR Server and switch to “Details1” tab.

 

Search a record with “hostname” prefix of a provisioned virtual machine using “SR Type Field 11” field

 

20.png

 

21.png

 

Use “ServiceRequest” ID to search the BMC_ContractLine record or manually create an entry for ContractLine in BMC_ContractLine form with below values


  • ContractLineType = ServiceOfferingLine
  • ContractLifeCycle = Active
  • StartDate = <currentDate or provisioned date if it’s known>
  • EndDate  = Proposed Decommission Date
  • ReconciliationIdentity = <Unique ID>
  • OwnerName/Submitter = User name
  • DatasetID = BMC.ASSET

 

Once you identify the BMC_ContractLine record, click "View Relationships" and in the same "Manage Relationships" window access the “Namespace" drop down menu and select "BMC.CORE" and "BMC_Component" from "Relationship Class".


Click on "Create" button. A new window will pop up. Replace Name field value to "CONTRACTLINECOVERSOFFERINGINSTANCE" and select "BMC.ASSET" as a DatasetId. In the "Select Destination" section, input respective "SERVICEOFFERINGINSTANCE" InstanceId.


To know the "ServiceOfferingInstance" id. Refer to point#3 to copy the ServiceOfferingInstance id.

Click on Save after the above configuration. This will create a relationship between ServiceOfferingInstance and ContractLine which covers ServiceOffering.


Follow the below steps to create or fix the OptionChoice and their prices records if they are missing from details pane on Service Instances-Services tab

 

22.png

 

Get the list of all prices (BMC_Price) associated with the optionChoice (option ID) and create new record for each if it’s not already created.


Create an entry for ContractLine in BMC_ContractLine form with below values or search the records using ‘SelectedOptionLine” as ContractLineType


  • ContractLineType = SelectedOptionLine
  • ContractLifeCycle = Active
  • StartDate = currentDate
  • EndDate  = Proposed Decommission Date
  • ReconciliationIdentity = <Unique ID>
  • OwnerName/Submitter = User name
  • DatasetID = BMC.ASSET
  • ServcieRequestId = <identified earlier from Service Requests form>

 

Create relation of option ContractLine to optionChoice, ServiceOffering ContractLine and all the Price objects created or identified earlier if records are missing.


Here are the details on the relationship to be created for various configuration items:


Relation between ServiceOffering ContractLine and Contract


  • Form : BMC_ContractComponent
  • Relationship Instance Name : CONTRACTLINEINCONTRACT
  • DatasetID = BMC.ASSET
  • Source.ClassID= BMC.CORE:BMC_CONTRACT
  • Destination.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Source Cloud Class: contract
  • Destination Cloud class : serviceofferingcontractline
  • CMDBRowLevelSecurity =  <equal to the CMDBRowLevelSecurity value of endpoints>

 

Relation between ServiceOffering ContractLine and ServiceOffering


  • Form : BMC_Component
  • Relationship Instance Name : SOCONTRACTSASSOLINE
  • DatasetID = BMC.ASSET
  • Source.ClassID= BMC_SERVICEOFFERING
  • Destination.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Source Cloud Class: serviceoffering
  • Destination Cloud class : serviceofferingcontractline
  • CMDBRowLevelSecurity =  <equal to the CMDBRowLevelSecurity value of endpoints>

 

Relation between ServiceOffering ContractLine and Price


  • Form : BMC_Component
  • Relationship Instance Name : CONTRACTLINEPRICE
  • DatasetID = BMC.ASSET
  • Source.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Destination.ClassID= BMC_PRICE
  • Source Cloud Class: serviceofferingcontractline
  • Destination Cloud class : price
  • CMDBRowLevelSecurity =  <equal to the CMDBRowLevelSecurity value of endpoints>

 

Relation between SelectedOption ContractLine and OptionChoice


  • Form : BMC_Component
  • Relationship Instance Name : OPTIONLINERECORDSOPTIONCHOICE
  • DatasetID = BMC.ASSET
  • Source.ClassID= BMC_OPTIONCHOICE
  • Destination.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Source Cloud Class: optionchoice
  • Destination Cloud class : selectedoptioncontractline
  • CMDBRowLevelSecurity =  <equal to the CMDBRowLevelSecurity value of endpoints>

 

Relation between SelectedOption ContractLine and ServiceOffering ContractLine


  • Form : BMC_Component
  • Relationship Instance Name : OPTIONLINEPARTOFSOLINE
  • DatasetID = BMC.ASSET
  • Source.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Destination.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Source Cloud Class: serviceofferingcontractline
  • Destination Cloud class : selectedoptioncontractline
  • CMDBRowLevelSecurity =  <equal to the CMDBRowLevelSecurity value of endpoints>

 

Relation between SelectedOption ContractLine and Price

 

  • Form : BMC_Component
  • Relationship Instance Name : CONTRACTLINEPRICE
  • DatasetID = BMC.ASSET
  • Source.ClassID= BMC.CORE:BMC_CONTRACTLINE
  • Destination.ClassID= BMC_PRICE
  • Source Cloud Class: selectedoptioncontractline
  • Destination Cloud class : price
  • CMDBRowLevelSecurity =  <equal to the CMDBRowLevelSecurity value of endpoints>

 

I hope information is useful to understand and fix the missing relationships of Contract and ContractLine for ServiceOffering, ServiceOfferingInstnace and Option/OptionChoices in BMC Cloud Lifecycle Management.

 

The information will not only help you to understand the concept but will also help you to troubleshoot and resolve missing ContractLine relationship issues on your own.


The shared information is also useful to understand the processing that occurs with Contracts and Contractline to make the functionality work seamlessly for the user. Please rate this blog below to let me know if this was useful.

 

Other Reference


The Pulse: Insights of Contract and ContractLine


The Pulse: Contracts and Pricing Model in BMC Cloud Lifecycle Management


You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Visit CLM Blogs. You can share the links with others if you find these useful.


Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

Share This:

Usage Scenarios


This video demonstrates how to use Blueprint Tags and their benefits. In this video I have shown how to use following type of tags in blueprint.

 

1: Blueprint Tags

2: Blueprint Document Level Tags


Blueprint Tags can be used to perform a group search or search a specific type of Service Blueprint in case you use common name for all Service Blueprints.


You can use Blueprint Document Level Tags to manage the version history of a Service Blueprint and also use it while configuring Reference Blueprint or Service Catalog.


The intended audience for this video are those who have already installed BMC Cloud Lifecycle Management 4.x and want to configure Service Blueprint and Service Catalog.


 

More like this

You can find more videos like this on BMC CLM How-to Videos Catalog


Products and Versions

      This video was made with the following products and versions:

          BMC Cloud Lifecycle Management 4.0 and 4.1

Share This:

In this post I will describe the flow and validations BMC Cloud Lifecycle Management-eZDeploy uses to import ZipKits.

 

By taking a closer look at how this works, you can troubleshoot any eZDeploy Import ZipKit issues on your own.

 

BMC ZipKits for Cloud are designed for the BMC Cloud Lifecycle Management solution. BMC ZipKits provide out-of-the-box content that you can use to create services that deploy specialized platforms such as operating systems with specific applications for your cloud end users.

 

Download the eZDeploy utility from here.

 

The eZDeploy utility is a command line-based interface utility that is used to export and import BMC Cloud Lifecycle Management service blueprints.

 

Refer to Configuring environment for the eZDeploy utility to configure your environment and profile before using eZDeploy utility.

 

The eZDeploy Import command initializes “ImportBlueprint” thread, which reads attributes from eZDeploy profile (<installDir>/bmc/bladelogic/eZDeploy-2.1-Linux/profiles) and starts parsing *.eZ file, used as an input.

 

Here is a sample of the import command:

 

import -name "/u01/bmc/bladelogic/eZDeploy-2.1-Linux/eZfiles/CLM 4.0-SQL Server 2012 on Windows 2008 R2.eZ" -profile arai41eZDeploy -prefix AR41

 

“BLDeployParser readSoftwares” parses the bldeploy file and prompts you to input the deploy file path for unbundled software.

 

It’s recommended to copy unbundled software to a common location that is accessible to the BMC Server Automation Server and the Virtual Center (VC).

 

eZDeploy prompts with the following message:  Enter path for unbundled softwares separated by (;)

 

For examples:

 

  • (Microsoft Windows) You can enter the path or URL on eZDeploy as a network path://host/pathIncludingInstallerFile.

 

Note: Ensure that the software is in a shared location and is accessible or eZDeploy will not accept the network path while importing a blueprint.

 

  • (Linux) You can provide mounted path if you are using eZDeploy Linux version: //eZdeploy/Sample Path

 

Example:

 

mount -t cifs -o username=administrator,password=bmcAdm1n //<Servername, which holds the unbundled software>/zipkits /mnt

 

Importing unbundled software flow validates Depot and Job folder and replaces the “depot id”, present in BLDeploy xml, with the actual ids.

 

eZDeploy uses the following blcli command to list all available templates at vCenter If you select an option to create a new VGP:

 

$BLCLI Virtualization listAllVirtualGuestPackagesByType $VGP_TYPE > $VGP_LIST_FILE

 

eZDeploy uses the following blcli command to list available vCenter before it start to create a virtual guest job:

 

$BLCLI Virtualization listVirtualEntityManagers VMWareVirtualCenter > $VC_LIST_FILE

where BLCLI="blcli -v $PROFILE_NAME -r BLAdmins"

 

Note: Acquire the credentials before running the blcli command. Use the following command to acquire the credentials:

 

blcred cred -acquire -profile $PROFILE_NAME -username $BSAUSERNAME -password $BSAPASSWORD

set BL_AUTH_PROFILE_NAME=$PROFILE_NAME

 

eZDeploy uses the following blcli command to fetch the datastore once you select vCenter:

 

$BLCLI Virtualization listVirtualEntitiesByEntityManagerServerIdAndEntityType $VC_ID VMwareDataStore > $DATASTORE_LIST_FILE

 

eZDeploy uses the following blcli command to get the list of VM templates available on the vCenter server

 

$BLCLI Virtualization listVirtualEntitiesByEntityManagerServerNameAndEntityType $VC_NAME VirtualMachineTemplates > $TEMP_LIST_FILE

 

eZDeploy replaces sample “Product Catalog ID” with actuals, once it creates the new virtual Guest Package. Finally eZDeploy imports the package with these information.

 

I have consolidated all the steps, involved during import and created a flowchart to help you understand the mechanism used by ezDeploy Imports flow:

ezdeploy_import_flow.png

 

I hope this information is useful to understand the flow and validations BMC Cloud Lifecycle Management-eZDeploy uses to import ZipKits.

 

Other References

 

Refer to Using eZDeploy import for more information.

 

Link to download zipkits

 

KA417764 - BLPackage job ran successfully but application did not install on target server or Error: Application Software creation failed - No such file or directory

 

KA415487 - [WARNING] Either the path is not accessible or software is not found at the given location.

 

KA418005 - Does eZDeploy 2.0 compatible with BMC CLM 4.1?

 

KA419379 - ezDeploy zipkit export fail with Service Offering - nullis associated with deleted deployment model

 

KA419417 - eZDeploy zipkit import fail with [ERROR] Error occurred while getting Authentication-Token.The parameter seedText cannot be null or empty

 

KA415491 - Error: Platform manager profile missing

 

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.
               
Visit CLM Blogs.You can share the links with others if you find these useful.

 

Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

Share This:

In this post I will describe the mechanism BMC Cloud Lifecycle Management uses to create a CHANGE request for an approval.

 

By taking a closer look at how this works, you can troubleshoot any Change request creation, use this information to integrate Change Management, or create Change Requests from your Custom Cloud Portals.

 

Change Management integration leverages the callout mechanism as a “pre-callout”, that is a callout that is executed before the actual operation starts executing. This is important when a Change Request is denied - the callout result will be negative and thus cancelling the actual operation. For example: Service Offering Instance creation.

 

We uses a single callout to Change Management as part of the flow to provision a Service Offering Instance. Here is the callout:

 

http://<MidTierServerName>:8080/arsys/plugins/CloudCallBackPlugin/params?server=<EnterpriseARServerName>&username=csmcallback&pwd=csmcallback&operation=CHECK_CHANGE_REQUIRED

 

The URL for the callout is related to the BMC_AccessAttributeValue configuration item with a BMC_Component relationship with a name of ATTRIBUTEVALUEFORCALLOUT:

 

1.png

 

Let’s take a look at the end to end use case:

 

Create a Requestable Offering with Change Policy – “Change Approval Required”. For example:

 

2.png

 

Submit a Service Offering Instance using this Requestable Offering which in turn will invoke the “pre-callout”.

 

Note: I am sharing some example of logs with the feature so you can compare if there are issues.

 

Snippet from CSM.log:

 

31 Oct 2014 16:33:42,575 [INFO] PROVIDER - [Thread=72c6fdca-e63f-4dfc-82ae-6f399a2697c1::feb75902-2153-4cc8-b832-668505ba5e9a::cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056(96)] [Class=WLMProviderInstanceImpl:buildVariableMap] - ##START WLM Callout[] invoke##     

Line 133300: 31 Oct 2014 16:33:42,576 [INFO] PROVIDER_REGISTRY - [Thread=72c6fdca-e63f-4dfc-82ae-6f399a2697c1::feb75902-2153-4cc8-b832-668505ba5e9a::cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056(96)] [Class=com.bmc.cloud.provider.registry.internal.ProviderRegistryImpl:forwardURI()] - Found Target Provider for ProvidedOperation : com.bmc.cloud.model.beans.Callout:INVOKE. Origin Provider Definition: WLM. Target Provider : CALLOUT_Provider:975dae92-4854-4eca-85af-359144705a8f

31 Oct 2014 16:33:42,585 [INFO] CALLOUT - [Thread=72c6fdca-e63f-4dfc-82ae-6f399a2697c1::feb75902-2153-4cc8-b832-668505ba5e9a::cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056(96)] [Class=HttpCalloutHandler:invoke] - HTTP Callout to URL :http://<MidTierServerName>:8080/arsys/plugins/CloudCallBackPlugin/params?server=<EnterpriseARServerName>&username=csmcallback&pwd=csmcallback&operation=CHECK_CHANGE_REQUIRED

31 Oct 2014 16:33:43,009 [INFO] CALLOUT - [Thread=72c6fdca-e63f-4dfc-82ae-6f399a2697c1::feb75902-2153-4cc8-b832-668505ba5e9a::cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056(96)] [Class=HttpCalloutHandler:invoke] - HTTP Callout sent successfully. No response received from Callee. Waiting till we get the callback

          Line 133305: 31 Oct 2014 16:33:43,009 [INFO] TASK - [Thread=72c6fdca-e63f-4dfc-82ae-6f399a2697c1::feb75902-2153-4cc8-b832-668505ba5e9a::cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056(96)] [Class=EventWorker:hibernate] - Task ready for hibernation.

 

WorkLoad manager send this pre-callout to MidTier server to validate if “Change” is require.

 

Snippet from armidtier log (from MidTier machine):

 

Note: DVM Module has an inbuilt logic to validate this information. Enable DVM logging, from midtier configuration tool (http://<MidTierServerName>:8080/arsys/shared/config/config_logs.jsp), in FINE mode to troubleshoot any Change or Option Choice related issues:

 

3.png

 

Oct 31, 2014 4:33:40 PM - FINE (com.remedy.log.DVMODULE) : (Thread 43) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - recieved new request from <PlatformManagerIPAddress> by user csmcallback

Oct 31, 2014 4:33:40 PM - FINE (com.remedy.log.DVMODULE) : (Thread 43) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Using the following Administrator user MidTier Service

Oct 31, 2014 4:33:40 PM - FINE (com.remedy.log.DVMODULE) : (Thread 43) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Operation getting executed ::: CHECK_CHANGE_REQUIRED

Oct 31, 2014 4:33:40 PM - FINE (com.remedy.log.DVMODULE) : (Thread 43) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - New callback task added to the queue

Oct 31, 2014 4:33:40 PM - FINE (com.remedy.log.DVMODULE) : (Thread 43) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - checking if the change request is enabled ...

 

CloudCallBackPlugin performs following validation before it send a notification to create a Change Request:

 

CMF:CloudTask:

 

CloudCallBackPlugin refers this form using “taskUUID” (generated by Platform Manager) and confirm the type of operation called in current request.

 

Snippet from armidtier log:

 

Oct 31, 2014 4:33:40 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - ===>#0 Searching CMF:CloudTask for taskUUID=cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056 with query ('taskInternalUUID' = "cdf4a2c2-56e7-4cc6-aace-6a94d1c1d056")

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - ===> Search returned 1 record(s)

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Modify Service Offering Instance is called

 

CMU:AIFInterfaceSummary:

 

CloudCallBackPlugin review the information present in “CMU:AIFInterfaceSummary” form for newly submitted SOI request using the Service Requests ID.

 

Snippet from armidtier log:

 

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Check the summary interface form for the following request id REQ000000002449

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Option requested is No Additional Disk

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Option requested is Test-Echo

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Option requested is Modify to 2 vCPU

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Looking for Service Offering Instance with reconcialiation id OI-65e7a836d809

 

CMF:CloudServicesFulfillment:

 

The Cloud Advance Interface Form submit triggers the SRM fulfillment process, which will perform a push fields action onto CMF:CloudServicesFulfillment using CAI events.

 

This form captures all the data requires to perform an action for the ServiceOfferingInstance and CloudCallBackPlugin refers this form for various data.

 

CMF:ChangeToRoMappingDetails:

 

The CloudCallBackPlugin looks up the CMF:ChangeToRoMappingDetails to identify the change template, and creates the change request by pushing the data to CHG:ChangeInterface_Create.

 

Snippet from armiditer log:

 

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Checking whether change is required for the following SRM SRDInstance ID :::::::::::SRGAA5V0FM4FNANDRJTOOV8S8I0H23

Oct 31, 2014 4:33:41 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Change Template ID842B2B080582PLPsTAOS1LAQ0dAA

 

4.png

 

CHG:ChangeInterface_Create:

 

CHG:ChangeInterface_Create is an interface form. If the required data to create a change request is pushed from any third party application, then out of the box workflow will create a new change request with that data after validation.

The change task, upon reaching Assigned (or upon change rejection), invokes the filter plug-in through a combination of AR workflows and the plug-in interface form CMF:FilterPlugin-Task.

 

Snippet from armidtier log:

 

Oct 31, 2014 4:33:50 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - *****************************************

Oct 31, 2014 4:33:50 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Successfully created change whose instance id is :::000000000001210

Oct 31, 2014 4:33:50 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - *****************************************

Oct 31, 2014 4:33:52 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Found Change in the Change Interface form ....AGGAA5V0FM4FNAN41CQ0K5FHK6HAYC

Oct 31, 2014 4:33:52 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Change timing :::6000

Oct 31, 2014 4:33:52 PM - FINE (com.remedy.log.DVMODULE) : (Thread 112) com.remedy.arsys.plugincontainer.impl.LogServiceImpl fine DV Module: CloudCallBackPlugin - Finding task based on the change instance

 

I hope this information is useful to understand the mechanism, BMC Cloud Lifecycle Management uses to create a Change Request for an approval.

 

This will help you to troubleshoot any Change creation issues or you can use this information to integrate Change Management or create Change Requests from your Custom Cloud Portals.

 

Other References:

 

Extending the integration with BMC Change Management

 

Integrating with BMC Change Management

 

Knowledge Articles

KA370290 - Enabling and disabling Change Management in Cloud LifeCycle Management (CLM)

KA362903 - Nothing happens when submitting a Service Request and SOI provisioning stuck at 0% progress

KA393273 - Cloud Change Request do no show under "Pending" in Change Console

KA344765 - Cloud Change remains in "Planning in Progress" status

KA380189 - CLM 3.0 Change Integration Failed with error "Failed to create Change Request"

 

The Pulse-Configuring CLM to use multitenant Change Management

 

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

 

Visit my other blogs. You can share the links with others if you find these useful.

 

Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

Share This:

In this post, I will describe the relationships of Contract and ContractLine with Pricing model and Option/OptionChoices in BMC Cloud Lifecycle Management. By taking a closer look at how this functionality works, we can troubleshoot and resolve any Pricing and Chargeback related issues on our own.

 

See my previous blog The Pulse: Insights of Contract and ContractLine, to understand basic Contract/ContractLine concepts described in this blog.

 

The contract line holds the service offering price shown to the user when they request the service offering. The fields for price are: PriceAmount (the amount), PricePeriod (time period), and PriceUOM (the pricing unit of measure). This price represents the on-going price for the service offering. The quantity is always assumed to be one service offering instance.

 

A BMC_ContractLine configuration item is created for each option choice selected. It is related to the parent contract line for the service offering through a BMC_Component relationship with the name

OPTIONLINEPARTOFSOLINE as shown below.

 

Pic1.png

 

Pic2.png

 

The contract line for the option choice is related to the BMC_OptionChoice configuration item with a BMC_Component relationship with a name of OPTIONLINERECORDSOPTIONCHOICE.

 

Pic3.png

 

The StartDate, EndDate and TerminationDate of this contract line have the same semantics as the Service Offering Line. The price fields for this contract line have the same meaning as they do for the service offering line (Refer to The Pulse: Insights of Contract and ContractLine).

 

pic4.png

 

Pic5.png

 

All of the above captures the price of the service offering and the selected options. There might be another price component, which is the one-time price entered when defining the request definition. The request definition is persisted as a BMC_RequestableOffering configuration item. The value of the OfferingType field is either null or set to Service. It is related to the BMC_ServiceOffering configuration item by a BMC_Dependency relationship with a Name of SOENABLESRO.

 

Pic6.png

 

The BMC_RequestableOffering configuration item is related to a BMC_Price configuration item by a BMC_Component relationship with a Name of OFFERINGPRICE.

 

Alternatively, you can use the ServiceRequestId field in the BMC_ContractLine for the service offering to query the service request and get the price. This method is better because it reflects the request definition price at the time the order was placed, whereas BMC_Price shows the current price.

 

If a service offering has post-deployment actions and the Add On radio button was set to Yes in the wizard, then a contract line is created when the user requests the post-deployment action.

 

Pic8.png

Pic7.png

 

The contract line has a ContractLineType of AddOnServiceLine. It is related to the contract line for the service offering with a BMC_Component relationship with the name of SOLINEISPARENTOFADDONLINE. The date fields and price fields in an add-on service line are the same as those in the service offering line.

 

Pic9.png

 

Pic10.png

 

I hope information is useful to understand the relationships of Contract and ContractLine with Pricing model and Option/OptionChoices in BMC Cloud Lifecycle Management.

The information will not only help you to understand the concept but will also help you to troubleshoot and resolve any Pricing and Chargeback related issue on your own.

 

Other References:

 

Knowledge Articles

KA390592 - Unable to edit price of Post Deploy Action.

KA373354 - How to create Chargeback Report in CLM?

KA365533 - Where does the CLM store the "Post Deploy Option" "pricing" information?

 

OOTB reports in Chargeback for BMC Cloud Lifecycle Management

 

Understanding Chargeback for BMC Cloud Lifecycle Management

 

Visit my other blogs. You can share the links with others if you find these useful.

 

Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

 

PS: At BMC we always strive to make our customers realize more value from our Products and be successful.

 

As you all know that we have introduced a new communication channel-“CHAT”. This gave our customers an additional option to contact us. For details, please refer Connect with BMC Support Team over Chat sessions.

 

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Share This:

In this post, I will describe the concepts and importance of Contract and ContractLine in BMC Cloud Lifecycle Management. By taking a closer look at how this functionality works, we can understand the behavior observed in the application at a deeper level.

 

BMC Cloud Lifecycle Management maintains information about tenants and the service offerings provisioned for those tenants by using several classes in the Database.

 

This information, which is available in contract lines, can be used to develop BMC Cloud Lifecycle Management customizations that provide showback or chargeback functionality.

 

When BMC Cloud Lifecycle Management onboards a new tenant, it ensures that there is a BMC_Organization configuration item for the tenant in which the Name field is set to the name of the tenant company.

 

1.png

 

BMC Cloud Lifecycle Management also creates an instance of BMC_Contract to represent the tenancy relationship between the provider and tenant.

 

2.png

 

Select the record and click on “View Related CI”.

 

3.png

 

The BMC_Contract configuration item has BMC_Contract.ContractType set to SLA (service level Agreement) and BMC_Contract.TenantCompany set to the tenant name.

 

4.png

 

5.png

 

Select the record and click on “View Relationship”

 

The BMC_Organization configuration item is related to the BMC_Contract configuration item with a BMC_Dependency relationship where the name is ORGANIZATIONISCUSTOMERFORCONTRACT.

 

6.png

 

In the following screenshot, the BMC_Contract.StartDate is the contract start date entered at the time the tenant is onboarded. The BMC_Contract.EndDate is the contract end date entered optionally when the tenant is onboarded. If the tenant is offboarded prior to the end date, BMC_Contract.TerminationDate is set to the offboarding date and the end date is not changed.

 

7.png

 

A BMC_Dependency with the name TAGGEDWITH relates the contract to an instance of BMC_Tag in which BMC_Tag.Name is set to Tenant and BMC_Tag.CategoryName is set to CSM.

 

8.png

 

9.png

 

When a service offering is provisioned, a BMC_ContractLine configuration item is created. This BMC_ContractLine is related to the tenant's BMC_Contract by a BMC_ContractComponent relationship with a Name of CONTRACTLINEINCONTRACT.

 

9.png

 

BMC_ContractLine.ContractLineType is set to ServiceOfferingLine.

 

10.png

 

The contract line is related to the BMC_ServiceOffering representing the service offering by a BMC_Component relationship with a Name of SOCONTRACTASSOLINE.

 

11.png

 

BMC_ContractLine.StartDate is the date the service offering was ordered. If a decommission date is entered during the order, the BMC_ContractLine.EndDate field is populated. If the service offering instance is manually decommissioned, BMC_ContractLine.TerminationDate is set to the decommission date and the end date is not changed.

 

12.png

 

13.png

 

BMC_ContractLine.ServiceRequestId holds the ID of the service request in SRM.

 

14.png

 

At the end of the provisioning process, the BMC_ContractLine is related to the BMC_ServiceOfferingInstance by a BMC_Component relationship where the Name is CONTRACTLINECOVERSOFFERINGINSTANCE.

 

15.png

 

Other References:

 

Up to version CLM 3.1 SP1, Contract lines for a service offering instance (SOI) are created in the enterprise BMC Remedy AR System server in draft mode and then transitioned to the cloud BMC Remedy AR System. After the SOI is provisioned, a notification for task completion is sent to the GUI, triggering the service request to be closed. After the service request is closed, Service Request Management changes the status of the contract lines to Active. If any error occurs in provisioning, the contract lines are set to Cancelled.

 

When you use the ServiceOfferingInstance bulkcreate request and the ServiceOfferingInstance applyOptionChoice request, contract lines for each SOI are created in a draft mode before the provisioning starts. If one of the SOIs fails, all contract lines are canceled even if the rest of the SOIs are provisioned successfully.

 

After CLM 3.1 SP1 patch 1, contract lines are created in the cloud AR System server first and then set to the Active state only after the provisioning is successful. These contract lines are then transitioned from the cloud AR System server to the enterprise AR System server.

 

Note: Since CLM 3.1 SP1 Patch1, BMC Cloud Lifecycle Management will not populate the BMC_ContractLine.EndDate even though there is a “Propose Decommision” date while submitting the “ServiceOfferingInstance” request.

 

The EndDate gets populated if you “extend” the “ProposeDecommission” date. This is a defect which will be fixed in latest hot fix on top of CLM 3.1 SP1 Patch 2.

 

KA358692 - "Modify Actions" (Options) are not creating "BMC_ContractLine" records

 

KA407880 - How to manually create a missing Service Offering relationship with Service Offering Instance?

 

I hope this information is useful to understand the processing that occurs with Contracts and Contractline to make the functionality work seamlessly for the user.  Please rate this blog below to let me know if this was useful.

 

Visit my other blogs. You can share the links with others if you find these useful.

 

Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

 

PS: At BMC we always strive to make our customers realize more value from our Products and be successful.

 

As you all know that we have introduced a new communication channel-“CHAT”. This gave our customers an additional option to contact us. For details, please refer Connect with BMC Support Team over Chat sessions.

 

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Share This:

In this post, I will share configuration steps which can help you configure your Additional Disk option and option choices which will allow placing VM’s Disks (multiple disks) on multiple VDR pools based on the size of the disk.

 

This is a key feature in the product to give customers greater control over disk space usage. This feature is being/has been introduced in following versions:

 

CLM 3.1 Hot-fix 14 (yet to be released). Contact support to collect the jar files.

 

CLM 3.1 SP1 Patch 2 Hot-fix 3, CLM 4.0 and CLM 4.1.

 

Here is an example of a use case:

 

You have a Requestable offering for SQL DB provisioning. The VM which hosts the database is supposed to have a specific number of drives (four or five for different purposes) available before the database provisioning job is executed.

 

While allotting drives with sizing options, you make use of the OPTIONS EDITOR to allow an end user to select a choice between SMALL or MEDIUM size. These sizing options are supposed to present pre-defined number of disks in each size with separate datastores for each disk drive. For example: One drive goes to one VDR Pool and the other goes to the 2nd VDR Pool and so on.

 

The basic configuration of Option, Option choices and Service Offering will be described in the documentation:

 

Adding additional system disks after deployment

 

Adding additional system disks to a service blueprint

 

Adding additional system disks during provisioning

 

Below is an example of configuring Option and Option Choices:

 

On the Service Catalog toolbar, click Options Editor

The Options Editor is displayed:

 

AddDisk1.png

 

I have configured only three option choices for “Additional Disk” option (type of Request Definition) but you can have many based on your requirements.

 

Select your option choice (I am selecting “Medium2”) and on the toolbar on the right side of the Options Editor under Option Choices for, click Option Choice Blueprint Configuration Editor.

 

The Option Choice Blueprint Configuration Editor is displayed.

 

Select Blueprint Configuration > Service Deployment Definition > Compute Resources > Additional System Disk:

 

AddDisk2.png

 

The New Blueprint Configuration window is displayed. In the New Blueprint Configuration window, enter the following values and click OK.

 

AddDisk17_001.png

 

The Option Choice Blueprint Configuration Editor is displayed:

 

AddDisk4.png

 

You can perform the same configuration for n number of Disks which you would like to add with provisioned virtual machine.

I have added three disks with following configurations:

 

AddDisk5.png

 

AddDisk6.png

 

After all configurations, the Option Choice Blueprint Configuration Editor is displayed as below:

 

AddDisk7.png

 

The Service Governor Workspace needs to be configured for “Virtual Disk Repository” policy as follow:

 

AddDisk8.png

 

You also need to configure your “Service Blueprint” and “Virtual Disk Repostiroy Pools” with TagGroup/Tags for specific Disk placement as follows:

Service Blueprint Configuration:

 

AddDisk9.png

 

Switch to Resource Management Workspace and Compute Pool section. Select the “Virtual Disk Repository” from “Pool Type”.

For my example, I have two instances of “Virtual Disk Repository” and I will be utilizing them to place the provisioned virtual machine’s disks:

 

AddDisk10.png

 

Edit each “Virtual Disk Repository” and add the respective TagGroup/Tag as follows:

 

AddDisk16.png

 

AddDisk17.png

 

After these configurations, add the Option’Option Choices to “Service Offering”:

 

AddDisk13.png

 

Let’s submit the request and select the appropriate option choice for disks:

 

AddDisk14.png

 

After a successful provisioning, we can review the VGJ (Virtual Guest Job) for Disk allocation:

 

AddDisk15.png

 

I have taken the above screenshot from VGJ (Virtual Guest Job) in BSA (BMC Server Automation).

The screenshot confirms the allocation of disks to their specific Data store based on the selected option choice configuration.

 

In case you would like control the selection of OS disks then define a TagGroup/Tag at Resource Set level or at the Compute level in Service Blueprint and set the same TagGroup/Tag on one of the VDR Pool where you would like place you OS (operating system) disks.

 

I hope this article helps to understand good ways to configure your Additional Disk option and option choices which will allow to place VM’s Disks (multiple disks) on multiple VDR pools based on the size of the Disk.

 

Visit my other blogs. You can share the links with others if you find these useful.


Please rate this blog, regarding the usefulness of the shared information, by clicking below option.

 

PS: At BMC we always strive to make our customers realize more value from our Products and be successful.

 

As you all know that we have introduced a new communication channel-“CHAT”. This gave our customers an additional option to contact us. For details, please refer Connect with BMC Support Team over Chat sessions.

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Share This:

In this post, I will share configuration steps which can help you configure your existing BMC Cloud Lifecycle Management stack when you introduce a new vCenter server while keeping the naming convention, for Clusters and Data-stores the same.

 

There can be multiple scenarios, example: vCenter server crash, scaling hardware, moving your Datacentre where you would like to introduce a new vCenter.

 

Introducing new vCenters creates configuration issues in your existing BMC Cloud Lifecycle Management stack because underlying GUID’s of different attributes, example: Clusters, Data-stores etc. are changed and it doesn’t match the ID’s present in Cloud DB.

 

Let me walk you through the configuration steps:

 

Retrieving “OLD VC GUID” provided that old vCenter server is still enrolled in Bladelogic Server Automation.

 

Open the following URL from a web browser:

 

https://<BSA-hostname>:<port>/type/PropertySetClasses/SystemObject/Server/?name=<Old VCname>&username=<user>&password=<password>&role=<role>

 

Replace following attributes with its actual values:

 

<BBSA-hostname>

<Port>

<Old VC Name>

<user>

<password>

<role>

 

This will return the GUID of the old vCenter. Example:

 

<RESTXMLResponse>

<PropertySetClassChildrenResponse>

<PropertySetClassChildren>

<PropertySetInstances totalCount="1">

<PropertySetInstance name="<BSA-Hostname>" description="" type="/type/PropertySetClasses/SystemObject/Server"dbKey="DBKey:SDeviceModelKeyImpl:2000100-2005700" objectId="e5d36224-cbca-44e3-83ae-d778ae27768f" uri="/id/SystemObject/Server/e5d36224-cbca-44e3-83ae-d778ae27768f" modelType="SERVER" modelTypeId="5004"/>

</PropertySetInstances>

</PropertySetClassChildren>

</PropertySetClassChildrenResponse>

</RESTXMLResponse>

 

You can refer to the values (highlighted) of “objectID” and “URI” attribute as the GUID of the vCenter.

 

In the BSA console, select the old vCenter from the server list. Change the Name property of that to the new vCenter and run a USP job. Confirm the IP address etc. For example:

 

P1.jpg

 

Once done, open Configuration – Property Dictionary view. Expand Built-in Property Classes. Select Connection and then click the Instances Tab. Select the connection to the old vCenter and edit the entry.

 

Change the Name, Description, CONNECTION_URL, CONNECTION_USER and CONNECTION_PASSWORD to that of the new vCenter. For example:

 

 

P2.jpg

 

In the Virtualization built-in property class select the Instances tab. Find the entry of the old vCenter and select edit.

 

Change the Name and VIRTUAL_ENTITY_CONNECTION entries to that of the new vCenter:

 

P3.jpg

 

In the properties of the vCenter, confirm the VIRTUALIZATION property (expand the “extended” property) is using the property specified previously (reference to new vCenter name). For example:

 

P4.jpg

 

After that, open the following URL from a web browser:

 

https://<BSA-hostname>:<port>/type/PropertySetClasses/SystemObject/Server/?name=<NewVCname>&username=<user>&password=<password>&role=<role>

 

Replace following attributes with its actual values:

 

<BBSA-hostname>

<Port>

<Old VC Name>

<user>

<password>

 

Confirm the GUID is the same as the old vCenter. This will mean, the GUID in the backend forms will not need to be replaced, if the GUID is different because the VC was re-enrolled in BSA, or the old vCenter was removed and new one added (effectively the same as re-enrolling), please follow the steps mention in KA365301 (https://kb.bmc.com/infocenter/index?page=content&id=S:KA365301) along with following steps:

 

Modifying the Cluster information:

 

Live browse the vCenter, select the cluster, right mouse click and select properties. Make a note of the domain-cxxx value:

 

P5.jpg

 

Open the BMC.CORE:BMC_Cluster form (http://<MidTierServerName>:<Port>/arsys/forms/<EnterpriseARServerName>/BMC.CORE%3ABMC_Cluster) at Cloud DB, find the BMC.ASSET entry for the cluster, select the Custom tab and view the entry for the ExternalID. Correct the domain-cxxx value, make a note of the old domain-cxxx value so you can search for this in the BMC.CORE:BMC_StorageVolume form in later stage:

 

P6.jpg

 

Change the highlighted fields to the correct value of the vCenter name and domain-cxxx:

 

P7.jpg

P8.jpg

P9.jpg

 

Open the BMC.CORE:BMC_StorageVolume form (http://<MidTierServerName>:<Port>/arsys/forms/<EnterpriseARServerName>/BMC.CORE:BMC_StorageVolume) do a search with %domain-cxxx% in the ExternalID field (where domain-cxxx is the old ID from previous steps above). Replace (if necessary) all of the old domain-cxxx values with the new value:

 

P10.jpg

 

Repeat the steps for all clusters onboarded to CLM.

 

Check if already enrolled servers in BSA are using the new VC in their Virtualization instance by opening the Virtualization built-in property class, select the Instances tab, find the instance and select Edit. Make sure the VIRTUAL_ENTITY_MANAGER matches the new vCenter.

 

I hope this article helps to understand good ways to reconfigure the BMC Cloud Lifecycle Management (CLM) stack when you introduce new vCenter, please share you experiences or feedback on this use case with comments below.

 

Visit my other blogs. You can share the links with others if you find these useful.

 

Please rate this blog, if shared information is useful, by clicking below option.

 

PS: At BMC we always strive to make our customers realize more value from our Products and be successful.

As you all know that we have introduced a new communication channel-“CHAT”. This gave our customers an additional option to contact us. For details, please refer Connect with BMC Support Team over Chat sessions.

 

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Share This:

In this post, I will share configuration steps on how to configure entitlement for a Tenant’s users, whether they belong to the same department/Organization or different, so that they can see different Service Request Definitions/Rquestable Offerings assigned to them.

 

An entitlement package is a set of requestable offerings that you can make available to tenants. These packages are created from the Entitlement Packages tab in the Service Catalog workspace, as described in Creating Entitlement Packages. For overview information about entitlement packages, see Entitlement Package Overview.

 

The configuration which we are discussing here will introduce multi-tenancy within Tenant’s departments so that users of Department A will not see Service Request Definitions/Rquestable Offerings assigned to the users of Deptartment B.

 

There can be multiple reasons you would like to hide specific SRD’s from set of users and make it available for few of that Tenant.

 

I used BMC Cloud Lifecycle Management 3.1 SP1 to perform all configurations.

 

Let’s take a look at the underlying configuration:

 

Use Demo account and open “Application Administration Console”:

First 1.jpg

Click on the Custom Configuration tab. Expand Service Request Management and then Entitlement:

SRM-EntitleManagement-1.png

Open the Entitlement Management form:

SRM-EntitleManagement-2.png

Click Entitlement Groups from the left hand side, select the Company Name (Tenant Company) from the drop down menu and then click “Create”:

SRM-EntitleManagement-3.png

Input group name and description:

2014-04-08_2005.png

Click "Save" button. Please perform this for all the groups which you would like to create.

For each group created, highlight it, click Add and select the users who should be a member of that group:

SRM-EntitleManagement-4.png

User ce2 (cloud end user2) has been added for “Tenant1-Windows-OS” and user ce3 (cloud end user3) has been added for “Tenant1-RHEL Only” Entitlement group:

SRM-EntitleManagement-5.png

User ce1 (cloud end user1) is the common user and has been added for both Entitlement Groups.

 

Click close after adding users to respective entitlement groups.

 

Select PED Management from the left hand side:

SRM-EntitleManagement-6.png

SRM-EntitleManagement-7.png

Click “Create”.

 

Enter in a name, select "Entitlement group" and select the relevant group from the ones you created above:

SRM-EntitleManagement-8.png

You will see the new rules added to the list and the groups associated with those rules:

SRM-EntitleManagement-10.png

Login into the BMC CLM Cloud Admin console, select the Service Catalog workspace, create a new service catalog or edit an existing one.

Create a new Service Offering or select an existing one.

 

Click Show Advanced Features:

SRM-EntitleManagement-11.png

If creating a new SRD (Service Request Definition) select Create Request Definition with SR Designer. If editing an existing SRD (Service Request Definition), select Edit Request Definition with SRD (Service Request Definition) Designer.

 

For an existing SRD (Service Request Definition), take the SRD (Service Request Definition) offline, then go to the Entitlements section. For a new Service Request Definition, complete the SRD (Service Request Definition) Designer entries up to the Entitlements section:

SRM-EntitleManagement-12.png

SRM-EntitleManagement-13.png

Do not add any Entitlement Packages just click Next:

SRM-EntitleManagement-14.png

Click on the Add button to add a new entitlement.

 

Select the entitlement you want to use:

SRM-EntitleManagement-15.png

Click Save.

 

The new entitlement is then added:

SRM-EntitleManagement-15_001.png

Continue with the SRD (Service Request Definition) Designer and save the SRD (Service Request Definition). Go back to the Welcome section and turn the SRD Online.

 

You can double check which SRDs (Service Request Definition), user can see by going back into the entitlement console where you configured the groups etc. and select “User Validation”:

SRM-EntitleManagement-16.png

Click Select, enter in the name of the company and click Search to return the users for that company. Highlight the user you want to validate:

SRM-EntitleManagement-17.png

SRM-EntitleManagement-18.png

Click “Select”.

 

Here we can see user “ce2 (Cloud End User2)” only has access to one SRD (listed in Matching SRDs) as it is a member of the “Tenant1-Windows-OS”:

SRM-EntitleManagement-19.png

“ce3 (Cloud End User3)” on the other hand can see other SRD (Service Request Definition) as he is a member of “Tenant1-RHEL Only”:

SRM-EntitleManagement-20.png

“ce1 (Cloud End User1)” on the other hand can see 2 SRDs (Service Request Definition) as it is a member of both “Tenant1-Windows-OS” and “Tenant1-RHEL Only”:

SRM-EntitleManagement-21.png

So, now we have done with the configuration, let’s see the results.

 

Let’s Logging into the My Cloud Services Console as “ce3 (Cloud End User3)”, and click on “New Service Request”. You can see only the offering assigned to the group, this user belongs to:

SRM-EntitleManagement-22.png

 

Logging into the My Cloud Services Console as “ce2 (Cloud End User2)”, and click on “New Service Request” You can see only the offering assigned to the group, this user belongs to:

SRM-EntitleManagement-23.png

Logging into the My Cloud Services Console as “ce1 (Cloud End User1)”, and click on “New Service Request”. We see both the offerings as this user was assigned to both groups.

SRM-EntitleManagement-23_001.png

 

In order for this to work you must make sure that the SRD’s (Service Request Definition) created are not assigned to any Entitlement Packages assigned to the company of which the users are members. Since in BMC CLM, the tenant is assigned to a package, and all users in this example are a member of the same tenant, then assigning the SRD (Service Request Definition) to an entitlement package will mean that all users, no matter what group they’re a member of, will be able to see the SRD (Service Request Definition) because they are all a member of the same tenant.

 

References:

Knowledge article: KA373369 - Message not in catalog--message number = 8029 (ARERR 8029)

 

Knowledge article: KA369405 - Logged in user can see all Service Offerings for all companies even though access has been restricted.

 

In this post, I covered configuration points and suggestions on how to configure entitlement for a Tenant’s users, whether they belong to the same department/Organization or different, so that they can see different SRD’s (Service Request Definition) assigned to them.

 

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

 

Visit my other blogs. You can share the links with others if you find these useful.

 

Please rate this blog, if shared information is useful, by clicking below option.

 

PS: At BMC we always strive to make our customers realize more value from our Products and be successful.

As you all know that we have introduced a new communication channel-“CHAT”. This gave our customers an additional option to contact us. For details, please refer Connect with BMC Support Team over Chat sessions.

 

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Share This:

In this post, I will share configuration steps on how to integrate and configure BMC Cloud Lifecycle Management 3.x with BMC Change Management so that there are different approvers of each company, configured in the Cloud environment, while maintaining the multi-tenancy concept.

 

BMC Change Management is an application in the BMC Remedy IT Service Management Suite that provides the ability to plan, schedule, implement, and track changes that need to be completed within your cloud infrastructure.

 

There is lot’s information out there on BMC Change Management and you can refer to the following video link if you are planning to integrate BMC Change Management with BMC Cloud Lifecycle Management and looking for it’s benefit:

 

BMC Change Management integration benefits (video)

 

The video provides an overview of the benefits of integrating BMC Cloud Lifecycle Management with BMC Change Management.

When you integrate BMC Cloud Lifecycle Management with BMC Change Management, service requests that you generate from a service offering instance in your cloud environment can generate change requests in BMC Change Management based on the service offering configuration.

 

The BMC Cloud Lifecycle Management change process differs from the standard change process. The BMC Cloud Lifecycle Management process does not require manual intervention by the Change Manager or Change Coordinator. For more information about user roles in BMC Change Management, see User roles. The standard change process stages, such as Request for Change, Scheduled for Review, and Scheduled, which require manual intervention, are not used by BMC Cloud Lifecycle Management.

 

The BMC Cloud Lifecycle Management change policies follow the change process stages as shown in the following figure:

 

Change Policy.jpg

The BMC Cloud Lifecycle Management-initiated change request already contains attributes and tasks, Therefore, the Change Manager or Change Coordinator does not need to add or update the change request. However, the Change Approver must approve or reject a change request by using the Change Approval Required policy.

 

If you are hosting a Cloud Environment and if each of your Tenants would like to have Change Integration in place where each of their Change Requests should only assign and visible to their own Change Approvers/Coordinator/Manager then the following configuration can help you achieving this use case.

 

Refer to Integrating with BMC Change Management which covers standard configurations then you can more easily follow the configuration covered in this blog.

 

A change policy determines how the service request is processed in BMC Change Management. Out-of-the-box, the following types of change policies are available:

  • No Change Required
  • Change Approval Required
  • Pre-Authorized Change
  • Audit-only Change

 

Except for the No Change Required policy, each change policy is mapped to a change class and its corresponding Change Templates.

In the following screenshot, I am using “Cloud Change - Approval Required” and will walk you through configurations.

 

Follow the below path to access/open this change template:

 

Default AR Home page -> Application Admin Console -> Custom Configuration -> Change Management -> Search Change Management Templates with the value on Template Category = Cloud Change Lifecycle.

 

Follow the default configuration displayed in following screenshot. Leave the Company name as “Calbro Services”.

 

chg1.png

Keep the field values blank from “Categorization” and “Assignment” tabs.

 

chg2.jpg

chg3.jpg

On the Authoring for Groups tab add the companies that will be using this change template (in this example Rose and Tenant1).

Change Approvers must belongs to a Support Group and the same should be used here.

 

chg4.jpg

Open the “Standard Cloud Task” and set the Company to “Global”. Here is the path to open it:

 

Default AR Home page -> Application Admin Console -> Custom Configuration -> Task Management System  -> Task Configuration -> Search Task Templates with the value on Name = Standard Cloud Task.

chg5.jpg

Assign the person under whose context the change task would be executed. This should ideally be any person from the Provider Company belonging to any of the Support Group.

 

chg6.png

Access the Approval Mapping form and create Approval Records for each company for which Change is required. Follow the below path to open the Approval Mapping form.

 

Default AR Home page -> Application Admin Console -> Custom Configuration -> Change Management -> Approval - > Approval Mapping.

 

Remember, after entering last name, you need to hit <Enter> key

 

In following example, we have configured this form for company name “Rose”. Configure this form for each company.

 

chg7.jpg

chg8.jpg

chg9.jpg

chg10.jpg

Add an Infrastructure Change Manager and Infrastructure Change Coordinator entry for each company in “Configure Application Assignments” form.

Here is the path to open this form:

 

Default AR Home page -> Application Admin Console -> Custom Configuration -> Foundation -> Configure Application Assignments

 

chg11.jpg

chg12.jpg

 

With this configuration, Change tickets will only be visible to its respective Tenant for approval.

 

Here are the screenshots of approval central logged in by two different Tenant’s Change Approvers who can only see the change tickets belongs to their own company:

 

chg13.jpg

chg14.jpg

 

You can refer following Knowledge Articles which covers known issues around Change Management Integration with BMC Cloud Lifecycle Management and other configuration details:

 

KA370290 - Enabling and disabling Change Management in Cloud LifeCycle Management (CLM)

 

KA393273 - Cloud Change Request do no show under "Pending" in Change Console

 

KA380189 - CLM 3.0 Change Integration Failed with error "Failed to create Change Ticket"

 

In this post, I covered configuration points and suggestions on how to integrate and configure BMC Cloud Lifecycle Management 3.x with BMC Change Management so that there are different approvers of each company, configured in the Cloud environment, while maintaining the multi-tenancy concept.

 

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

 

Visit my other blogs. You can share the links with others if you find these useful.

 

Please rate this blog, if shared information is useful, by clicking below option.

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.

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.

Filter Blog

By date:
By tag: