It is tempting to only rely on defaulting webhooks to ensure any
changes to the OperatorConfig updates the .collection.externalLabels
and rules.externalLabels fields with the default project, location, and
cluster labels.
However, for many cases, where an OperatorConfig already exists and the
operator is restarted with this change, a webhook will not be invoked
and the change to the generated Prometheus config's external_labels will
never happen.
So we add the defaulting webhook as well as implicit logic to fill in
the generated config external_labels at runtime.
Another approach could be to omit the mutating webhook entirely, however
if we can reflect the state of the config in our custom resources, we
should. This gives users a more clear and explicit sense of what is
being configured.
It is tempting to only rely on defaulting webhooks to ensure any changes to the OperatorConfig updates the .collection.externalLabels and rules.externalLabels fields with the default project, location, and cluster labels.
However, for many cases, where an OperatorConfig already exists and the operator is restarted with this change, a webhook will not be invoked and the change to the generated Prometheus config's external_labels will never happen.
So we add the defaulting webhook as well as implicit logic to fill in the generated config external_labels at runtime.
Another approach could be to omit the mutating webhook entirely, however if we can reflect the state of the config in our custom resources, we should. This gives users a more clear and explicit sense of what is being configured.