Don't delete resources unless field managers match #3407
Conversation
blampe
added
the
impact/no-changelog-required
Does the PR have any schema changes?Looking good! No breaking changes found. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3407 +/- ##
==========================================
+ Coverage 41.08% 41.12% +0.03%
==========================================
Files 87 87
Lines 12900 12917 +17
==========================================
+ Hits 5300 5312 +12
- Misses 7205 7208 +3
- Partials 395 397 +2 ☔ View full report in Codecov by Sentry. |
blampe
force-pushed
the
blampe/delete-after-create-field-manager
branch
from
0a9b5d5 to
4817d79
Compare
blampe
force-pushed
the
blampe/delete-after-create-field-manager
branch
from
4817d79 to
c0839d3
Compare
| } | ||
| actualSSAManagers = actualSSAManagers.Insert(f.Manager) | ||
| } | ||
| if c.ServerSideApply && !actualSSAManagers.Has(c.FieldManager) { |
There was a problem hiding this comment.
As written this would also no-op in cases where the object was updated with CSA.
We can narrow this by also checking actualSSAManagers is non-empty, so we know the live object was at least touched by pulumi.
|
Note that Helm uses labels to track ownership and to drive adoption. |
|
What makes me uncomfortable is the idea that Pulumi being a field manager is evidence of ownership. Imagine that some other manager has taken over all but one field, say Skipping deletion when there's other field managers would not work either, because the autoscaler that is controlling the replicas has no intention of owning the object. I would advocate for adopting a Helm-like strategy of using ownership labels. The use of the standard
Note that Helm recently added a flag called Interesting to note that Helm has special treatment of CRDs, e.g. they're never deleted. Consider doing the same: See also: #3000 @blampe are you alright with closing this PR? |
This fixes the delete-after-create problem by reviving #2999 using field managers (as Eron suggested) instead of annotations to confirm ownership before deleting a resource.
If the resource was created with SSA, and we don't find the expected field manager, then we no-op instead of deleting the resource. The intended effect is to remove it from our state so the "upserted" manager can continue owning it.
This is technically a breaking change in behavior for some edge cases, but I think it is justified by the potential severity of our delete-after-create bug.