Add SSA option to transfer field manager on delete

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we’ll work with you on design, scheduling, etc.)

Issue details

Related to https://github.com/pulumi/pulumi-kubernetes/issues/2108

Add an option for resources that use SSA to specify a field manager to take ownership of the resource on delete. Users currently have to manage any field transfer themselves to allow some resources to be deleted.

This is an example of an error they might see:

error: this Patch resource is currently managing a required field, so it can't be deleted directly. Either set the 'retainOnDelete' resource option, or transfer ownership of the field before deleting: spec.template.spec.volumes[0].configMap.name

We should be able to set a new field manager for any required fields rather than raising an error in these cases.

Workaround

See https://github.com/pulumi/pulumi-kubernetes/issues/2108#issuecomment-1199934365 for details on a workaround.

Affected area/feature

[lblackstone]

After further work on this, and discussing the results with @squaremo, we decided that this isn’t the right direction to go. “Unpatching” a resource can lead to unexpected results, and should be an opt-in feature rather than the default.

Instead, we plan to make the following changes:

1. Make retainOnDelete the default behavior for Patch resources, with a new opt-in flag to “unpatch” for cases where this works cleanly (e.g., for additive patches like new ConfigMap entries, or adding labels/annotations).
2. Add a warning if retainOnDelete + the new unpatch option are both enabled.
3. Add additional documentation that covers common patching scenarios.
4. Update error messages

As a result of these planned changes, it should be far less common for users to encounter this error message since the resource would be retained by default.

[squaremo]

For convenience, prior discussion is neatly summarised here: https://github.com/pulumi/pulumi-kubernetes/issues/2011#issuecomment-1152377430 (and the whole thread is useful context)