Change tracking for custom resource updates

The Operator provides built-in visibility into changes made to custom resources by logging modifications during the reconciliation process. This includes both spec updates and status field changes that are made by the Operator and user, and thus tracking operational events and configuration drift over time.

What gets logged?

Resource creation
When a new custom resource is created, the Operator logs its initial state.
Example:
INFO certificatemanager-resource  Created a new CertificateManager resource:
==============================================================================
INFO sipenviroment-resource  Created a new SIPEnvironment resource:
==============================================================================
Spec changes
Any modifications to specifications of a custom resource are logged with a before and after difference.
Example:
INFO certificatemanager-resource  Changes detected in CertificateManager resource:
==============================================================================
INFO certificatemanager-resource  Updated CertificateManager resource:
==============================================================================
INFO sipenvironment-resource Changes detected in  SIPEnvironment resource:
==============================================================================
INFO sipenvironment-resource Updated SIPEnvironment resource:
==============================================================================
Status updates
The Operator also tracks and logs status field changes, showing how the system state evolved in response to controller logic.
Example:
INFO controller.omsgateway  Old OMSGateway status:
INFO controller.omsgateway  Updated OMSGateway status:
INFO controller.sipenvironment  Old SIPEnvironment status:
INFO controller.sipenvironment  Updated SIPEnvironment status:

Benefits

  • Provides transparent insight into how a custom resource evolved over time.
  • Useful for debugging, audits, and Operator observability.
  • Logs are printed at the controller level, visible in kubectl logs of the controller pod.

Limitations

These logs do not include user identity that is who triggered the change. For complete audit trails including user, timestamp, IP, consider enabling Kubernetes Audit Logging.

Supported resources

The spec and status change tracking is enabled for the following resources:
  • SIPEnvironment
  • IVServiceGroup
  • PromisingServiceGroup
  • UtilityServiceGroup
  • OptimizerServiceGroup
  • OMSGateway
  • CertificateManager

Command to view logs

Access the logs using the following command for Kubernetes. For others, use the appropriate command for your chosen platform.
kubectl logs <controller-pod-name> -n <namespace>

Specify the <controller-pod-name> from the following two controller pods which run in the instance, one for Sterling Intelligent Promising and the other for omsGateway.

sip-controller-manager pod
This pod checks for Sterling Intelligent Promising and other service group changes.
omsgateway-controller-manager pod
This pod checks for omsGateway and certificate manager changes.