Rollouts trigger a double rollout for Flux managed workloads

[hamishforbes]

Is your feature request related to a problem? Please describe.
If a workload (e.g. Deployment or StatefulSet) is deployed into a cluster via Flux, then setting the restartedAt annotation will trigger a second rollout at some point in the future when Flux reconciles the configuration.

This is also a problem if you use kubectl (or any other tooling) to trigger a rollout or otherwise modify the deployment template.
The solution is to configure the field manager as flux-client-side-apply when setting the annotation.

Describe the solution you'd like
Make the Field Manager configurable when applying the rollout restart annotation.

I'm not sure where this would be configured ideally, I can see 3 options at least
a) As a config flag/env var on the operator pod itself
b) A field in the CRD e.g. spec.rolloutRestartTargets[{ kind: 'Deployment', name: 'foobar', fieldManager: 'flux-client-side-apply'}]
c) An annotation on the target workload - vso.secrets.hashicorp.com/fieldManager: 'flux-client-side-apply'

I've tested this works by just hardcoding the field manager and deploying the custom operator to a dev environment

[koschos]

To provide a cross-reference, there is an open issue on the Flux repository: FluxCD Issue #2755.

In this comment, it specifically mentions the incompatibility with VSO.

[BradErz]

My understanding of the flux implementation is that it just needs a field manager defined which doesn't have a prefix with any of these values defined in this default list:
https://github.com/fluxcd/kustomize-controller/blob/444b8d265e2ecd10f63b2ae8a6bf95072bec2c86/internal/controller/kustomization_controller.go#L707-L728

So, in reality, we can add a field manager with any other value.

I suggest adding a field manager called vault-secrets-operator to the annotation vso.secrets.hashicorp.com/restartedAt. This then implies vault-secrets-operator is the one managing this annotation.

You can see an underlying example of what kubectl rollout restart command adds:

            {
                "manager": "kubectl-rollout",
                "operation": "Update",
                "apiVersion": "apps/v1",
                "time": "2025-02-20T10:46:53Z",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:spec": {
                        "f:template": {
                            "f:metadata": {
                                "f:annotations": {
                                    "f:kubectl.kubernetes.io/restartedAt": {}
                                }
                            }
                        }
                    }
                }
            }

And its documented under the server side apply documentation:
https://kubernetes.io/docs/reference/using-api/server-side-apply/

Are the maintainers willing to accept a patch for this issue?

[koschos]

The issue can be closed because the Vault Secrets Operator (VSO) already provides a correct and compatible field manager name via Kubernetes' built-in mechanism. There is no need to modify VSO's behavior.

How fieldManager is Derived

Kubernetes assigns the fieldManager to a resource using one of two methods:

1. Explicitly set via query parameters (?fieldManager=xyz) when making a request.
2. Implicitly inferred from the User-Agent header if fieldManager is missing.

The Kubernetes API server automatically derives the fieldManager from the User-Agent header when it's not explicitly provided in the request. This behaviour is documented in the Kubernetes documentation: Server-Side Apply - Field Managers

Example: Kubernetes API server extracts the field manager from User-Agent in patch.go

objToUpdate = p.fieldManager.UpdateNoErrors(currentObject, objToUpdate, managerOrUserAgent(p.options.FieldManager, p.userAgent))

How VSO's fieldManager is Set

The VSO does not explicitly set fieldManager, so Kubernetes derives it from the User-Agent string set by the Kubernetes Go client's default configuration:

DefaultKubernetesUserAgent()

func DefaultKubernetesUserAgent() string {
       return buildUserAgent(
           adjustCommand(os.Args[0]),
           adjustVersion(version.Get().GitVersion),
           gruntime.GOOS,
           gruntime.GOARCH,
           adjustCommit(version.Get().GitCommit))
}

Here, os.Args[0] is the binary name, which for VSO is "vault-secrets-operator", set in the Dockerfile entrypoint.

[benashz]

Closing this issue, since the fieldManager is being set correctly when triggering a rollout restart. The associated PR also breaks the rollout restart e2e tests.