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

Replacing failed but no changes to be done on next run #2382

Closed
avdv opened this issue May 10, 2023 · 2 comments
Closed

Replacing failed but no changes to be done on next run #2382

avdv opened this issue May 10, 2023 · 2 comments
Assignees
Labels
area/providers impact/reliability Something that feels unreliable or flaky kind/bug Some behavior is incorrect or out of spec resolution/no-repro This issue wasn't able to be reproduced size/M Estimated effort to complete (up to 5 days).

Comments

@avdv
Copy link

avdv commented May 10, 2023

What happened?

I was running pulumi up and observed an error while replacing a k8s secret:

Updating (infra):
     Type                          Name                              Status                   Info
     pulumi:pulumi:Stack           infra  **failed**               1 error
 +-  └─ kubernetes:core/v1:Secret  solver-svc-acct    **replacing failed**     [diff: ~data]; 1 error


Diagnostics:
  kubernetes:core/v1:Secret (solver-svc-acct):
    error: resource cluster-ns/solver-svc-acct was not successfully created by the Kubernetes API server : Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 0

  pulumi:pulumi:Stack (infra):
    error: update failed

Outputs:
   ...

Resources:
    +-1 replaced
    14 unchanged

Duration: 15s

This happened due to passing non-base64 encoded data to the data argument for core.v1.Secret's constructor.

After fixing the problem, running pulumi up again results in no changes to be done:

Previewing update (infra):
     Type                 Name                              Plan     
     pulumi:pulumi:Stack  infra           


Resources:
    16 unchanged

The resource was indeed not created in the k8s cluster, but seems like Pulumi's state is saying otherwise.

BTW, running pulumi refresh deleted the secret from the state and I could run pulumi up again.

Expected Behavior

I would expect that Pulumi does not register the resource as created, if there was an error.

And hence I would expect the resource would be created the next time running pulumi up.

Steps to reproduce

new k8s.core.v1.Secret(
    "solver-svc-acct",
    {
      metadata: {
        name: "solver-svc-acct",
        namespace: "cluster-ns",
      },
      type: "Opaque",
      data: {
        "key":  << use some invalid base64 data first, then encoded base64 >> ,
      },
    }
  );

Output of pulumi about

CLI          
Version      3.55.0
Go Version   go1.20
Go Compiler  gc

Plugins
NAME    VERSION
nodejs  unknown

Host     
OS       nixos
Version  22.11 (Raccoon)
Arch     x86_64

This project is written in nodejs: executable='/nix/store/dnhhyhfql3cs9jmrhd3a05620higxy0i-nodejs-18.14.2/bin/node' version='v18.14.2'

Current Stack: infra

TYPE                                       URN
kubernetes:core/v1:Secret                  urn:pulumi:infra::project::kubernetes:core/v1:Secret::solver-svc-acct
...

Found no pending operations associated with infra

Backend        
Name           x1
URL            gs://da-cn-pulumi-stacks
User           claudio
Organizations  


### 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). 
@avdv avdv added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels May 10, 2023
@kpitzen
Copy link
Contributor

kpitzen commented May 16, 2023

Hi @avdv - thank you for opening this issue. We very much appreciate your clear reproduction, and will look into this as soon as we can - I expect this to be a relatively straightforward fix regarding how the provider reports success back to the engine, but it will take a bit more in-depth investigation to be sure.

Thanks again!

@kpitzen kpitzen added area/providers impact/reliability Something that feels unreliable or flaky size/M Estimated effort to complete (up to 5 days). and removed needs-triage Needs attention from the triage team labels May 16, 2023
@lblackstone lblackstone self-assigned this Jul 14, 2023
@lblackstone lblackstone added the resolution/no-repro This issue wasn't able to be reproduced label Jul 14, 2023
@lblackstone
Copy link
Member

I wasn't able to reproduce this with the v4 provider, so I suspect this may have been fixed by #2445.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/providers impact/reliability Something that feels unreliable or flaky kind/bug Some behavior is incorrect or out of spec resolution/no-repro This issue wasn't able to be reproduced size/M Estimated effort to complete (up to 5 days).
Projects
None yet
Development

No branches or pull requests

3 participants