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

Field manager name conflicts for resources created with client-side apply #2352

Closed
lblackstone opened this issue Apr 5, 2023 · 0 comments · Fixed by #2355
Closed

Field manager name conflicts for resources created with client-side apply #2352

lblackstone opened this issue Apr 5, 2023 · 0 comments · Fixed by #2355
Assignees
Labels
kind/bug Some behavior is incorrect or out of spec p1 A bug severe enough to be the next item assigned to an engineer resolution/fixed This issue was fixed
Milestone

Comments

@lblackstone
Copy link
Member

lblackstone commented Apr 5, 2023

What happened?

Recent versions of kubernetes began setting a field manager for all resources based on the name of the executable performing the update, even for resources managed using client-side apply. This can cause problems for resources that were created using client-side apply that are subsequently updated using server-side apply because the field manager name may conflict.

Related: #2262

Expected Behavior

Updating a resource created using client-side apply mode should not cause conflicts based on the field manager name.

Steps to reproduce

  1. Create a resource using client-side apply mode with pulumi-kubernetes
  2. Change the provider to use SSA mode and update a value on the resource
  3. Run an update
  4. The field manager name will conflict and raise an error

Example:

import * as k8s from "@pulumi/kubernetes";

const provider = new k8s.Provider("k8s", {
    enableServerSideApply: false, // change to true on step 2
});
const appLabels = { app: "nginx" };
const deployment = new k8s.apps.v1.Deployment("nginx", {
    spec: {
        selector: {matchLabels: appLabels},
        replicas: 3,
        template: {
            metadata: {labels: appLabels},
            spec: {
                containers: [
                    {
                        name: "nginx",
                        image: "nginx:1.16", // change to "nginx:1.17" on step 2
                    },
                ],
            },
        },
    }
}, {provider});

Results in the following error:

  kubernetes:apps/v1:Deployment (nginx):
    error: Preview failed: 1 error occurred:
    	* the Kubernetes API server reported that "default/nginx-f43bda57" failed to fully initialize or become live: Server-Side Apply field conflict detected. see https://www.pulumi.com/registry/packages/kubernetes/how-to-guides/managing-resources-with-server-side-apply/#handle-field-conflicts-on-existing-resources for troubleshooting help
    : Apply failed with 1 conflict: conflict with "pulumi-resource-kubernetes" using apps/v1: .spec.template.spec.containers[name="nginx"].image

Output of pulumi about

n/a

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@lblackstone lblackstone added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team p1 A bug severe enough to be the next item assigned to an engineer and removed needs-triage Needs attention from the triage team labels Apr 5, 2023
@lblackstone lblackstone self-assigned this Apr 5, 2023
@lblackstone lblackstone added this to the 0.87 milestone Apr 5, 2023
@lblackstone lblackstone changed the title Field manager name conflicts for client-side apply Field manager name conflicts for resources created with client-side apply Apr 5, 2023
@pulumi-bot pulumi-bot added the resolution/fixed This issue was fixed label Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec p1 A bug severe enough to be the next item assigned to an engineer resolution/fixed This issue was fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants