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

Helm Release does not pickup changes in locally stored templates #2118

Closed
benbust opened this issue Aug 5, 2022 · 6 comments · Fixed by #2568
Closed

Helm Release does not pickup changes in locally stored templates #2118

benbust opened this issue Aug 5, 2022 · 6 comments · Fixed by #2568
Assignees
Labels
area/helm customer/feedback Feedback from customers customer/lighthouse Lighthouse customer bugs and enhancements kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Milestone

Comments

@benbust
Copy link

benbust commented Aug 5, 2022

What happened?

When referencing a Chart with a local path, if I apply changes to the templates and run pulumi up, the release is not updated.

As a workaround, I've set forceUpdate: true.

Steps to reproduce

Using kind:

kind create cluster --name pulumi

const kind = new k8s.Provider("kind", {context: "kind-pulumi"});
const release = new Release("pulumi-release",{
    name: "pulumi-test",
    createNamespace: true,
    namespace: "pulumi-test",
    chart: "./pulumi-chart-test/",
    forceUpdate: true,
    values: {
        pulumi: "world",
    }
    },{
        provider: kind
    }
);

The pulumi-chart-test/templates folder contains a simple manifest and if I add the below:

apiVersion: v1
kind: ConfigMap
metadata:
  name: pulumi
  annotations:
+    test: "update"
data: 
    hello: {{ .Values.pulumi }}

And run pulumi up nothing happens.

Expected Behavior

The Helm release should be updated with any addition to its manifests.

Actual Behavior

Nothing happened, the release is not updated according to the changes in the underlying manifest.

Versions used

CLI          
Version      3.37.2
Go Version   go1.18.4
Go Compiler  gc

Plugins
NAME        VERSION
kubernetes  3.20.2
nodejs      unknown

Host     
OS       darwin
Version  11.6
Arch     x86_64

This project is written in nodejs: executable='/Users/benjamin/.nvm/versions/node/v16.15.1/bin/node' version='v16.15.1'

Current Stack: helmRelease

TYPE                           URN
pulumi:pulumi:Stack            urn:pulumi:helmRelease::helm::pulumi:pulumi:Stack::helm-helmRelease
pulumi:providers:kubernetes    urn:pulumi:helmRelease::helm::pulumi:providers:kubernetes::kind
kubernetes:helm.sh/v3:Release  urn:pulumi:helmRelease::helm::kubernetes:helm.sh/v3:Release::pulumi-release


Found no pending operations associated with helmRelease

Backend        
Name           pulumi.com
URL            https://app.pulumi.com/btuffreau
User           btuffreau
Organizations  btuffreau, starburstdata

Dependencies:
NAME                VERSION
@pulumi/kubernetes  3.20.2
@pulumi/pulumi      3.37.2
@types/node         14.18.23

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).

@benbust benbust added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Aug 5, 2022
@guineveresaenger
Copy link
Contributor

Hi @benbust - thank you for filing this bug!

Also, many thanks for the workaround; it's always helpful for others who may be running into a similar issue.

We will need to add a check to detect source file changes here and will be taking a look soon.

@guineveresaenger guineveresaenger removed the needs-triage Needs attention from the triage team label Aug 8, 2022
@lukehoban
Copy link
Member

I believe to address this we'd need to either:

  1. Support passing an Asset/Archive here (which takes care of tracking checksums and diffs)
  2. Add an (optional) checksum input which the user can compute themselves and which will trigger updates

@jdmaguire
Copy link
Contributor

I tried the above workaround and it wasn't working for me. An alternative workaround was this code:

const myChart = new k8s.helm.v3.Release("argo-configuration", {
  chart: "../charts/my-chart",
  name: "my-chart",
  namespace: deployNamespace,
  values: {
    random: Math.random()
  }
}, { parent: this });

@lblackstone
Copy link
Member

Possibly related to #748

@amkartashov
Copy link

w/a I use:

  • change version in Chart.yaml
  • pass version in helm.v3.Release args

This is kinda logical - chart version should be bumped on chart change.

@mnlumi mnlumi added customer/feedback Feedback from customers customer/lighthouse Lighthouse customer bugs and enhancements labels Aug 2, 2023
@mnlumi mnlumi added this to the 0.94 milestone Aug 31, 2023
@EronWright EronWright self-assigned this Sep 13, 2023
@EronWright
Copy link
Contributor

Similar to: hashicorp/terraform-provider-helm#515

Upon some investigation, the ideal seems to be to use the checksum of the rendered template, as opposed to that of the raw files. This would allow Pulumi to take into account the computed output. I observe that the template is rendered eagerly by the provider (during Check) to re-compute the resource names. I'll investigate further.

EronWright added a commit that referenced this issue Sep 17, 2023
### Proposed changes

This PR fixes a usability problem with the
`kubernetes:helm.sh/v3:Release` resource when using a local chart. With
this fix, Pulumi automatically detects changes to the rendered output of
the chart and performs a Helm upgrade accordingly. It does this by
persisting a SHA256 checksum of the chart output into the Pulumi stack
state.

Users may suppress change detection with the `ignoreChanges` option,
i.e. `ignoreChanges: ["checksum"]`.

**Upgrade considerations**: after upgrading the provider, users should
expect to see a diff (`checksum` property) and a corresponding Helm
upgrade. Helm upgrades are generally idempotent.

### Related issues (optional)
Closes #2118
@pulumi-bot pulumi-bot added the resolution/fixed This issue was fixed label Sep 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/helm customer/feedback Feedback from customers customer/lighthouse Lighthouse customer bugs and enhancements kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants