Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(policy): set an informative field manager on patches #13394

Merged
merged 1 commit into from
Nov 25, 2024

Conversation

olix0r
Copy link
Member

@olix0r olix0r commented Nov 25, 2024

When the policy controller patches a status, it sets the field manager to be that of the Kind of resource being managed. Per the Kubernetes documentation, this field should describe the controller that is making the change:

Managers identify distinct workflows that are modifying the object (especially
useful on conflicts!), and can be specified through the fieldManager query
parameter as part of a modifying request. When you Apply to a resource, the
fieldManager parameter is required. For other updates, the API server infers a
field manager identity from the "User-Agent:" HTTP header (if present).

When you use the kubectl tool to perform a Server-Side Apply operation,
kubectl sets the manager identity to "kubectl" by default.

This commit sets the field manager to "linkerd.io/policy-controller", as is used in status values.

@olix0r olix0r requested a review from a team as a code owner November 25, 2024 18:02
@olix0r olix0r changed the title fix(policy): set an informative field manager on patches chore(policy): set an informative field manager on patches Nov 25, 2024
When the policy controller patches a status, it sets the field manager to be
that of the Kind of resource being managed. Per the Kubernetes documentation,
this field should describe the controller that is making the change:

> Managers identify distinct workflows that are modifying the object (especially
> useful on conflicts!), and can be specified through the fieldManager query
> parameter as part of a modifying request. When you Apply to a resource, the
> fieldManager parameter is required. For other updates, the API server infers a
> field manager identity from the "User-Agent:" HTTP header (if present).
>
> When you use the kubectl tool to perform a Server-Side Apply operation,
> kubectl sets the manager identity to "kubectl" by default.

This commit sets the field manager to "linkerd.io/policy-controller", as is used
in status values.
@olix0r olix0r enabled auto-merge (squash) November 25, 2024 18:34
@olix0r olix0r disabled auto-merge November 25, 2024 18:37
@olix0r
Copy link
Member Author

olix0r commented Nov 25, 2024

Before:

    - apiVersion: gateway.networking.k8s.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          .: {}
          f:parents: {}
      manager: gateway.networking.k8s.io
      operation: Update
      subresource: status
      time: "2024-11-25T18:40:30Z"

After:

    - apiVersion: gateway.networking.k8s.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          f:parents: {}
      manager: linkerd.io/policy-controller
      operation: Update
      subresource: status
      time: "2024-11-25T18:45:06Z"

@olix0r olix0r enabled auto-merge (squash) November 25, 2024 18:46
@olix0r olix0r merged commit 6a46f69 into main Nov 25, 2024
43 checks passed
@olix0r olix0r deleted the ver/patch-manager branch November 25, 2024 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants