Enabling optional features

You can enable the optional features of License Service to get extra benefits.

License Service works in the background and does not require any configuration for license compliance. However, you can perform optional configuration to enable additional License Service features and get extra benefits. By default, the features are disabled and transparent. To enable these features, edit the IBMLicensing custom resource.

Available features:

Editing the IBMLicensing custom resource

Learn how to edit the IBMLicensing custom resource to enable the additional features.

Chargeback - Filtering the license usage data by user-defined groups

This feature is available from IBM Cloud Pak® foundational services version 3.7.x.

For license compliance purposes, License Service automatically collects information about the highest license usage of your products in all namespaces in the entire cluster. However, for internal accounting, you might need to calculate the expenses associated with the license usage of the individual internal organizations or business divisions in your company, that is - chargeback. Thanks to the new feature, you can define groups and assign namespaces to these groups. Then, you can retrieve the license usage reports for the individual groups. As a result, you can analyze and understand the contribution of each group to the overall license usage, especially during the peak, or for any time range. You can also see which group has the highest and lowest usage, and what software is mostly used throughout your organization.

To filter the license usage by groups, divide your namespaces into groups by labeling them. You can assign multiple namespaces to one group. If you do not assign a namespace to any group, you do not track its contribution to the overall usage. Next, enable filtering feature in the IBMLicensing custom resource, and retrieve the license usage with the /products API with groupName parameter.

Filtering by groups

Note: The following procedure is dedicated to tracking the license usage of products that are licensed with Virtual Processor Core (VPC) and Processor Value Unit (PVU). For the products that are licensed with other license metrics, check the product documentation to check if filtering by groups is supported and on what conditions.

Complete the following procedures to enable filtering by group.

1. Define groups

To define groups, add the group labels to your namespaces by completing the following steps:

  1. Log in to your OpenShift cluster console.

  2. Go to Administration > Namespaces.

  3. Find the namespace that you want to label.

  4. Click the overflow action menu next to the namespace name, and select Edit labels.

  5. Add the following label to the list:


    where groupName is the name of the group that you will use to filter the data.

    Important: The name of the group must be other than default. This name is reserved for the development use only.

  6. Repeat these steps for the remaining namespaces that you want to divide into groups. You can assign more than one namespace to one group.

2. Enable filtering by group

To enable filtering by group, complete the following steps.

  1. Edit the IBMLicensing custom resource.

  2. Add the following parameters to the IBMLicensing section, under spec:

    • To enable filtering by group, add the following line:

      chargebackEnabled: true
    • Optional: To set the retention period for which the filtered data is stored, add the following line and specify the number of days for storing the filtered data:

      chargebackRetentionPeriod: <number of days>

      Note: Specify the chargebackRetentionPeriod to define the number of days after which the data is deleted. If you do not add chargebackRetentionPeriod to the custom resource, the retention period is set to 62 days.

Retention period

Storing information about license usage of the products that are installed on the namespaces that belong to the groups requires extra memory. Because of that, the filtered data can only be stored for a limited time. By default, the chargebackRetentionPeriod is set to 62 days. In case of issues with retrieving the filtered data, decrease the retention period to avoid overflow.

Note: Remember to regularly generate audit snapshot to preserve all the data required for compliance purposes. Generate audit snapshot at least once during the span of retention period.

To estimate the retention period that best suits your environment consider the number of products that are deployed in the namespace, and the number of groups that you define.

Given that the maximal accepted size of the storage is 1 MiB, which equals 1048576 bytes, you can use the following formula to estimate the maximal retention period for your environment:

1048576 / (number of products * number of groups * 11.85)

The outcome is the number of days to which you should set the retention period for the specified number of products and groups.

The following table shows the estimated retention period for different number of products and groups expressed in the number of days:

Environment Small Medium Large
Products up to 50 50-75 more than 75
Suggested retention period 1 quarter (90 days) 2 months (60 days) 1 month (30 days)

3. Retrieve license usage data by group

To retrieve the license usage data for the defined group, use the /products API and use the groupName parameter for filtering.

You can retrieve license usage for more than one group by adding more groupName=<groupName> parameters to get the total contribution of these groups.

API URL: <License Service URL>/products?token=<token>&groupName=<groupName>

For more information, see Retrieving license usage of products.

Understanding the reported values

The API retrieves the license usage of products that are deployed in the namespaces that are assigned to the defined group or groups. The license usage is expressed by the metricQuantity value which is the number of metric units that the group contributes to the overall usage of the product on the cluster. As a result the metricQuantity be expressed by a fraction.

Example scenario

You can use chargeback to track license usage for your products in different divisions in your organization. First, think about how many groups you can distinguish, and gather information about which namespaces these groups use.

In this example, the organization needs to define two groups HR and Procurement. The organization follows the procedure and defines the groups by adding the labels to appropriate namespaces, and then enables filtering by group. As the organization defines only 2 groups that use only one product, the chargeback retention period is set to 90 days as recommended for small environments.



  "name": "IBM Cloud Pak for Integration",
  "id": "c8b82d189e7545f0892db9ef2731b90d",
  "metricPeakDate": "2021-07-08",
  "metricQuantity": 1.5



  "name": "IBM Cloud Pak for Integration",
  "id": "c8b82d189e7545f0892db9ef2731b90b",
  "metricPeakDate": "2021-07-08",
  "metricQuantity": 0.5

Based on the example, the HR group contributes 1.5 VPCs of the overall usage of IBM Cloud Pak for Integration on the peak date, while Procurement group contributes 0.5 VPC.



  "name": "IBM Cloud Pak for Integration",
  "id": "c8b82d189e7545f0892db9ef2731b90d",
  "metricPeakDate": "2021-07-08",
  "metricQuantity": 4

As the overall license usage of IBM Cloud Pak for Integration on the peak date equals 4, and the HR group contributes 1.5 VPCs and the Procurement group 0.5 VPC, you can calculate that the remaining usage, 2 VPCs, is used outside of the defined groups.

The following image represents the license usage on the cluster.

The image shows the breakdown of the license usage on the cluster.

The following statements summarize the license usage calculations for the cluster:

Information Value Comments
Overall usage of IBM MQ Advanced on the cluster 1 vCPU + 1 vCPU + 2 vCPUs = 4 vCPUs To calculate the overall usage of the bundled product, add the vCPUs that are used by all the instances of the bundled product in the cluster. vCPU is calculated according to the IBM Container Licensing rules. For more information, see IBM Container Licenses on Passport Advantage.
Metric conversion for IBM MQ Advanced 2:1 Metric conversion is defined in the licensing document of the product
Metric converted quantity for IBM MQ Advanced on the cluster 4 vCPUs * 2:1 = 2 VPCs To calculate the metric converted quantity, multiply the overall usage of the bundled product on the cluster by the metric conversion ratio. As a result, the value represents the number of VPCs that the bundled product contributes on the cluster
Converted metric contribution of IBM MQ Advanced in the HR group 1 vCPU /4 vCPUs * 2 VPCs = 0.5 VPC To calculate the contribution of the bundled product within the group divide the number of the vCPUs used within the group by the overall number of vCPUs used on the cluster and multiply it by the metric converted quantity for the cluster.

You can base on the example to similarly calculate the converted metric contribution of any bundled product within the group.

Enabling hyperthreading

This feature is available from IBM Cloud Pak® foundational services version 3.11.x.

License Service supports hyperthreading, also referred to as Simultaneous multithreading (SMT) or Hyper-Threading (HT). To take advantage of the benefits of using this technology, enable hyperthreading in License Service. Hyperthreading might have great impact on your licensing costs. For more information, see Hyperthreading.

You can enable hyperthreading for the clusters where all working nodes have SMT or HT enabled. To enable hyperthreading, complete the following steps.

  1. Edit the IBMLicensing custom resource.

  2. Add the following lines to the IBMLicensing section, under spec:

        threadsPerCore: <number of threads>

    Note: Set the value of the threadsPerCore parameter to the lowest number of threads per core in your infrastructure. The following table lists the acceptable values.

Table 1. List of acceptable values
Value Description
1 Hyperthreading is not enabled.
2 HT and SMT2 is enabled with the declared number of 2 threads per core.
4 SMTP4 is enabled with the declared number of 4 threads per core.
8 SMTP8 is enabled with the declared number of 8 threads per core.