Changing the data on a ConfigMap with enableDryRun: true on EKS 1.19/ K3S v1.20.4 causes the following error:
kubernetes:core/v1:ConfigMap (test2):
error: resource default/pierlucg-test was not successfully created by the Kubernetes API server : configmaps "pierlucg-test" already exists
Run pulumi up twice with the following code:
const eksProviderDry = new k8s.Provider('eksdry', {
enableDryRun: true,
kubeconfig: 'mykubeconfig'
});
const configMapTest = new k8s.core.v1.ConfigMap(
'this-will-fail',
{
data: {foo: `${Date.now()}`},
metadata: {
name: `failing-configMap`,
},
},
{provider: eksProviderDry},
);
const eksProvider = new k8s.Provider('eks', {
kubeconfig: 'mykubeconfig'
});
const configMapWorking = new k8s.core.v1.ConfigMap(
'this-will-succeed',
{
data: {foo: `${Date.now()}`},
metadata: {
name: `fonctioning-configMap`,
},
},
{provider: eksProvider},
);
This will be the result the second time:
Previewing update (mystack.dev):
Type Name Plan Info
pulumi:pulumi:Stack myproject-mystack.dev 1 error
+- 鈹溾攢 kubernetes:core/v1:ConfigMap this-will-succeed replace [diff: ~data]
+- 鈹斺攢 kubernetes:core/v1:ConfigMap this-will-fail replace [diff: ~data]; 1 error
Diagnostics:
pulumi:pulumi:Stack (myproject-mystack.dev):
error: preview failed
kubernetes:core/v1:ConfigMap (this-will-fail):
error: Preview failed: resource default/failing was not successfully created by the Kubernetes API server : configmaps "failing" already exists
Using Typescript
EKS Server Version: v1.19.8-eks-96780e
Pulumi Version: v3.1.0
"@pulumi/kubernetes" Version: "^3.1.0"
I also tested with a local K3S cluster and the issue still occurs.
Might affect https://github.com/pulumi/pulumi-kubernetes/issues/1556
Changing the data on a ConfigMap with
enableDryRun: true
I assume this does not repro with enableDryRun: false? In which case it sounds like an issue with the server-side diff support. cc https://github.com/pulumi/pulumi-kubernetes/issues/1556 which is tracking making that the default.
I tried with enableDryRun: false and the configmap updated was replaced just fine.
@lblackstone could not using auto-naming be the cause of this issue as well?
@lblackstone could not using auto-naming be the cause of this issue as well?
Yes, quite possibly. Sorry for the troubles here. We may need to rethink the provider's behavior in the case where the resources are not auto-named.
For future reference, the related issue is #1567
I'll leave the decision whether to close this issue up to you. With my newly found understanding (thank you), I now know how to avoid this problem. That being said, I agree that there might be a better way to at least provide a more meaningful error.
Thanks again!