You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
It must possible issues with JSON marshalling mutations and remove default values setting for CRD object.
Previously, it was possible, that object was modified during unmarshalling, it causes object mutation after client.Update call. Since object state wasn't restored to the original version after marshalling.
#946
…ate (#950)
It must possible issues with JSON marshalling mutations and remove default values setting for CRD object.
Previously, it was possible, that object was modified during unmarshalling, it causes object mutation after client.Update call. Since object state wasn't restored to the original version after marshalling.
#946
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.
The text was updated successfully, but these errors were encountered: