Epic: SAP OpenMCP Metering Operator

[GenosseOtt]

SAP Metering Operator

The Charging Target Label

On the OpenMCP onboarding cluster, users can create Projects, Workspaces and ManagedControlPlanes.
On each level customers are able to set the openmcp.cloud.sap/charging-target label. This label is used to determine the target for the billing of OpenMCP usage.
The label value, also known as charging target, must have the following format: btp:$ga-id, where $ga-id is a BTP global account ID.

The charging target label is only mandatory and enforced on Projects and inherited by Workspaces and ManagedControlPlanes, but is also possible to override the value on Workspaces and ManagedControlPlanes.

Rough steps

1. Establish charging label to measure traction, create metering operator
   • https://github.tools.sap/kubernetes/k8s-lifecycle-management/issues/1408

2. Establish approach to charge customers per hour (costs per cluster, per hour)

3. Determine if Excel or Unified Meterig service approach is way to go (ask managers, they are 200 steps ahead already)

Out of scope - for v2

• Sophisticated charging considering actual usage of MCPs (they are very diverse, we cannot charge them all the same long-term)

Metering Operator

The SAP metering operator is a Kubernetes operator that fulfills several purposes for OpenMCP resource usage metering.

1. It validates that, at least, that Projects have the openmcp.cloud.sap/charging-target label set and that the label value is in the correct format. If the charging target label is set on Workspaces and ManagedControlPlanes, the operator should validate that the value has the expected format.
2. Withing a certain interval, it collects the amount of ManagedControlPlanes for a charging target. The collected data should also include the Projects, Workspaces and ManagedControlPlanes names as metadata. The interval is configurable and should be set in the operator configuration. We agreed to use a interval of 24 hours initially.
3. The collected metering data is sent to the SAP metering service endpoint. The endpoint is configurable and should be set in the operator configuration.
4. Spike: The operator creates a metering status resource that contains the collected data, or an aggregation of the collected data (whatever is more feasible) that has been collected during the last interval. The status resource should be located on the OpenMCP onboarding cluster and should not be accessible by customers. The status resource can then be used by the SAP metrics operator to create metrics for OpenMCP operations dashboards.

Open Questions

1. Should the operator include ManagedControlPlanes which are not in a ready state? Does the operator needs to differentiate between failed stats that are cause by customer misconfiguration and internal errors that are not caused by the customer?
2. How do we detect that metrics has been successfully sent to the SAP metering service? Should we retry sending the metrics if the service is not available?
3. Do we need to have audit logging enabled to log metering rungs by the operator?
4. If we ever want to change the format of the charing target label value, should the metering operator an automatic migration? If not, how should the operator handle values that are not in the expected format?

Tasks