Expose config to disable upsert behavior #3000
Conversation
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 #3000 +/- ##
==========================================
- Coverage 29.86% 29.79% -0.08%
==========================================
Files 63 63
Lines 8353 8384 +31
==========================================
+ Hits 2495 2498 +3
- Misses 5634 5660 +26
- Partials 224 226 +2 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
In an earlier experiment along these lines (i.e. using Create rather than Apply), I observed that metadata.managedFields is significantly different. I was concerned that some migration logic might be needed.
We have CSA-to-SSA logic elsewhere in the provider. Would this be involved on a subsequent update?
| @@ -325,6 +325,7 @@ func Test_Creation(t *testing.T) { | |||
| DedupLogger: logging.NewLogger(context.Background(), host, urn), | |||
| Resources: resources, | |||
| ServerSideApply: tt.args.serverSideApply, | |||
| EnableUpsert: tt.args.serverSideApply, | |||
There was a problem hiding this comment.
| EnableUpsert: tt.args.serverSideApply, | |
| EnableUpsert: tt.args.enableUpsert, |
| @@ -90,6 +90,16 @@ func PulumiSchema(swagger map[string]any) pschema.PackageSpec { | |||
| Description: "BETA FEATURE - If present and set to true, allow ConfigMaps to be mutated.\nThis feature is in developer preview, and is disabled by default.\n\nThis config can be specified in the following ways using this precedence:\n1. This `enableConfigMapMutable` parameter.\n2. The `PULUMI_K8S_ENABLE_CONFIGMAP_MUTABLE` environment variable.", | |||
| TypeSpec: pschema.TypeSpec{Type: "boolean"}, | |||
| }, | |||
| "enableUpsert": { | |||
There was a problem hiding this comment.
Should we reverse the polarity of this field, so that it is false by default?
| @@ -177,6 +187,15 @@ func PulumiSchema(swagger map[string]any) pschema.PackageSpec { | |||
| Description: "BETA FEATURE - If present and set to true, allow ConfigMaps to be mutated.\nThis feature is in developer preview, and is disabled by default.\n\nThis config can be specified in the following ways using this precedence:\n1. This `enableConfigMapMutable` parameter.\n2. The `PULUMI_K8S_ENABLE_CONFIGMAP_MUTABLE` environment variable.", | |||
| TypeSpec: pschema.TypeSpec{Type: "boolean"}, | |||
| }, | |||
| "enableUpsert": { | |||
| Description: "If present and set to false, the provider will surface errors if a create operation would overwrite existing resources in the cluster.", | |||
There was a problem hiding this comment.
Maybe should mention that this is for ssa mode only.
|
Let me state my opinion here, that Kubernetes SSA is designed for a multi-party authoring experience (where multiple parties apply their intentions to a given object), but design-wise says nothing about object lifecycle. For example, it doesn't answer the question of "who should delete this object, my party or your party?". An auto-scaler, for example, would not expect to create or to delete a given object, merely to control the replicas field while the object exists. Pulumi has features like "import" and "retainOnDelete" to control an object's lifecycle, and there's no good reason that SSA should complicate that, in my opinion. I agree with disabling upsert, perhaps opt-in in v4 and always disabled in v5. |
This exposes opt-in provider configuration to disable upsert behavior. When this is set we will use CSA for creation and surface "already exists" errors when we attempt to overwrite something.
I called the config
enableUpsertto be consistent with some of our other configs (although I'd preferdisableUpsertsince that makes it more obvious what the default behavior is).An E2E test is included and I'll try to add some units around this as well.
Fixes #2926.