Enable "helm upgrade --install" equivalent behavior #1247
Conversation
|
|
|
As I noted over in the #425, I've released a test build of this for people to kick the tires on: |
n-oden
force-pushed
the
upgrade-mode
branch
from
a8d9938
to
72b261e
Compare
|
Bump: could someone re-approve the checks? I've updated the PR to address the failing ones. |
This comment was marked as resolved.
This comment was marked as resolved.
|
Updated, all tests passing locally. |
|
@bd-spl gentle nudge? :) |
I welcome this change, albeit have no merging powers here. Please try reaching out the owners of this repository. |
|
@alexsomesan can I prevail on you to take a look here? I think this is ready to go. |
|
@alexsomesan nudge? :) |
|
@alexsomesan this is now rebased on top of the current main branch. Is there any chance this could be reviewed before EOY? I've got an internal project that's rather blocked by this and would like to avoid the temptation to use a forked version without a formal 👍 on the approach from your team. |
|
Happy New Year everyone! @alexsomesan my apologies for being a bother, but would it be possible to get the test workflows approved? The tests are passing locally and I believe absent any other feedback that this is ready for submission. |
n-oden
force-pushed
the
upgrade-mode
branch
2 times, most recently
from
3c6f6e8
to
599bca0
Compare
n-oden
changed the title
|
Is there any news on this? |
|
@lodmfjord I'm honestly not sure what's going on here; we seem to have fallen into a bit of a hole. In the meantime if you'd like to kick the tires on this you can use https://registry.terraform.io/providers/n-oden/helm/0.0.2 which is a fork of the hashicorp helm provider with this PR cherry-picked on top. Obviously the caveat there is that there's no guarantee that they'll ever merge this back upstream, or hashicorp might ask for incompatible state schema changes before they do, so using it in production is very much an at your own risk proposition and I probably can't personally commit to keeping a fork up to date in perpetuity if this PR never gets accepted. |
|
@arybolovlev @SarahFrench @appilon @jrhouston my apologies for the spam, but I'm hoping to get someone to approve running the checks on this PR, which seems to have gotten a little lost. |
|
We're having a look at this, but I personally have to familiarise myself with the helm upgrade mechanism itself before I can evaluate this PR. I'm doing that, in the background of other tasks. |
|
@alexsomesan many thanks, and if I can answer any questions please don't hesitate to ask |
|
@alexsomesan just checking in: I've rebased on the current upstream main branch and dealt with the merge conflicts. Could you approve the testing workflows? |
|
@alexsomesan thanks! I'm a little baffled as to why the 0.12 test is failing, and the output gives no hint. Can you re-run that with debug logging enabled? |
|
FWIW I cobbled together a local test environment and was unable to reproduce the test failure using tf v0.12.31: https://gist.github.com/n-oden/99afa11625eee21c49efddf6ebc896db (It did eventually fail, down in |
|
After some more experimentationI'm gonna strongly assert that whatever was going on with the v0.12.31 test in the previous run was not a result of this PR. I set up a parallel PR in my own repo to make the tests run there and you can see here that it's passing: odenio#1 @alexsomesan I've rebased this against the current main/HEAD -- can you re-approve the test runs? |
This PR adds a (potentially) idempotent "upgrade mode" to the provider, mimicing the behavior of `helm upgrade --install` as defined in https://github.com/helm/helm/blob/main/cmd/helm/upgrade.go To wit: an `upgrade` block is added to the resource attributes, consisting of tool boolean values: `enable` and `install`. If `enable` is true, this causes the provider to create a `*action.Upgrade` client, and attempts to perform an upgrade on the named chart. If `install` is true, it will first create an `*action.History` client to determine if a release already exists; if it does not find one it creates an `*action.Install` client and attempts to install the release from scratch. If a release _is_ found, an upgrade is performed. This allows the resource to potentially co-exist with, e.g., CI/CD systems that could potentially install the release out-of-band from terraform's viewpoint.
Description
This PR adds a (potentially) idempotent "upgrade mode" to the provider, mimicking the behavior of
helm upgrade --installas defined in https://github.com/helm/helm/blob/main/cmd/helm/upgrade.goTo wit: an
upgradeblock is added to the resource attributes, consisting of two boolean values:enableandinstall.If
enabledis true, this causes the provider to create a*action.Upgradeclient, and attempts to perform an upgrade on the named chart. Ifinstallis true, it will first create an*action.Historyclient to determine if a release already exists; if it does not find one it creates an*action.Installclient and attempts to install the release from scratch. If a release is found, an upgrade is performed. This allows the resource to potentially co-exist with, e.g., CI/CD systems that could potentially install the release out-of-band from terraform's viewpoint.Acceptance tests
Release Note
Release note for CHANGELOG:
References
Community Note