I have a question regarding using the source_labels/sourceLabels and/or target_label/targetLabel in a spec.remoteWrite inlineUrlRelabelConfig (probably global RelabelConfig is also affected).
version: victoriametrics/operator:v0.42.3
It doesn't matter if you deploy a VMAgent with the underscore version for inlineUrlRelabelConfig like this:
that leads to an apply conflict for remoteWrite changes as per this definition for the manager that handled the initial creation of the VMAgent object with a Server-Side Apply.
│ Error: victoria/application failed to run apply: Apply failed with 1 conflict: conflict with "manager" using operator.victoriametrics.com/v1beta1: .spec.remoteWrite
│ Please review the fields above--they currently have other managers. Here
│ are the ways you can resolve this warning:
│ * If you intend to manage all of these fields, please re-run the apply
│ command with the `--force-conflicts` flag.
│ * If you do not intend to manage all of the fields, please edit your
│ manifest to remove references to the fields that should keep their
│ current managers.
│ * You may co-own fields by updating your manifest to match the existing
│ value; in this case, you'll become the manager if the other manager(s)
│ stop managing the field (remove it from their configuration).
│ See http://k8s.io/docs/reference/using-api/server-side-apply/#conflicts
I can't remember having this issue before, but we also didn't change remoteWrite for a longer time.
Also existing VMAgents aren't affected by this. The operator does not set this double version parameters. Only if we create new ones.
Hi,
I have a question regarding using the source_labels/sourceLabels and/or target_label/targetLabel in a spec.remoteWrite inlineUrlRelabelConfig (probably global RelabelConfig is also affected).
version: victoriametrics/operator:v0.42.3
It doesn't matter if you deploy a VMAgent with the underscore version for inlineUrlRelabelConfig like this:
or the version without underscore like this:
it ends up building this:
The issue we have now is, in any case the operator claims the spec.remoteWrite field in managedFields:
that leads to an apply conflict for remoteWrite changes as per this definition for the manager that handled the initial creation of the VMAgent object with a Server-Side Apply.
I can't remember having this issue before, but we also didn't change remoteWrite for a longer time.
Also existing VMAgents aren't affected by this. The operator does not set this double version parameters. Only if we create new ones.