opentelemetry-operator
opentelemetry-operator copied to clipboard
open-telemetry
Rethink what "Replicas" mean in the status object
We might want to think again what "replicas" mean, especially when talking about mode: sidecar. Also, do we count all currently running replicas, or the desired ones? Should we have multiple values, like desired/current that the Deployment has?
As replicas could be dynamic, would it be better to just expose as metric instead of via status?
For an operations person using kubectl, it might be easier to expose the number of replicas on kubectl get otelcols. Nothing prevents us from adding that as a metrics as well, though.
Guess so - although how often would the "current replicas" be updated. Desired count is more stable so easer to include.
Current replicas might have a high variance in case of mode: sidecar, if we are to count them, as it would basically reflect the number of pods that include the sidecar.
One might affect the other, but they are different problems. Here, we want to tell the users how many replicas there are for a given CR. For sidecars, it would be the count of sidecars that were injected for a given CR. For a daemonset or deployment, it's the current number of replicas for the underlying daemonset/deployment, which is what #775 is handling.
For sidecars, it would be the count of sidecars that were injected for a given CR.
This sounds like different information than replicas. It is somehow similar to the instrumentation CR status, where we want to tell the user how many or to which workloads the auto-instrumentation was injected.
