What would you like to be changed:
Refactor ManagedHandler and FederatedManagedHandler to use the central projection.ExtractProjectionGroupsFrom helper function and export the correct count.
Why is this needed:
The recently added extractProjectionGroupsFrom function (in PR #166) provides a centralized way to group metrics/resources by projection values.
|
func extractProjectionGroupsFrom(list *unstructured.UnstructuredList, projections []v1alpha1.Projection) projectionGroups { |
However, the ManagedMetric and FederatedManagedMetric handlers do not use it, instead containing their own simplified logic.
They set the value to 1 for each datapoint. This violates the DRY principle, makes the codebase harder to maintain, and results in incorrect metric data being exported, as described in
#92.
managedHandler datapoint:
|
// Set the value to 1 for each resource |
|
dataPoint.SetValue(1) |
federatedManagedHandler datapoint:
What would you like to be changed:
Refactor ManagedHandler and FederatedManagedHandler to use the central projection.ExtractProjectionGroupsFrom helper function and export the correct count.
Why is this needed:
The recently added extractProjectionGroupsFrom function (in PR #166) provides a centralized way to group metrics/resources by projection values.
metrics-operator/internal/orchestrator/projectionhelper.go
Line 151 in eb91a69
However, the ManagedMetric and FederatedManagedMetric handlers do not use it, instead containing their own simplified logic.
They set the value to 1 for each datapoint. This violates the DRY principle, makes the codebase harder to maintain, and results in incorrect metric data being exported, as described in #92.
managedHandler datapoint:
metrics-operator/internal/orchestrator/managedhandler.go
Lines 107 to 108 in eb91a69
federatedManagedHandler datapoint:
metrics-operator/internal/orchestrator/federatedmanagedhandler.go
Line 90 in eb91a69