-
Notifications
You must be signed in to change notification settings - Fork 116
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
Support explicitly passing --kube-version to helm #2563
Support explicitly passing --kube-version to helm #2563
Comments
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes This PR exposes the helm template `--kube-version` argument so it can be manually specified in situations when there is no access to the Kubernetes API server (e.g running a diff in CSA mode with no connection to the cluster). Prior to this merge: * If there were zero k8s contexts --> this field was unset meaning helm would default to some old version (1.20.0 at the time of writing) if it couldn't connect to the k8s context * 1+ k8s contexts --> would always try to contact the API server to get the version leading to an error if the API server was unreachable. This variable will override the behavior in either case, but is mostly useful in the first case or when the context in the second case is malformed / unreachable. ### Related issues (optional) <!--Refer to related PRs or issues: pulumi#1234, or 'Fixes pulumi#1234' or 'Closes pulumi#1234'. Or link to full URLs to issues or pull requests in other GitHub repositories. --> Closes pulumi#2563
Mistakenly put a |
This commit exposes the helm template `--kube-version` argument so it can be manually specified in situations when there is no access to the Kubernetes API server (e.g running a diff in CSA mode with no connection to the cluster). Prior to this merge: * If there were zero k8s contexts --> this field was unset meaning helm would default to some old version (1.20.0 at the time of writing) if it couldn't connect to the k8s context * 1+ k8s contexts --> would always try to contact the API server to get the version leading to an error if the API server was unreachable. This variable will override the behavior in either case, but is mostly useful in the first case or when the context in the second case is malformed / unreachable. Closes #2563 --------- Co-authored-by: Ramon Quitales <[email protected]>
Did this make it into Releases to, or just Chart? I'm seeing the same issue using an imported Release, and am not familiar enough with the code here to understand what it affects 😄 I am using 4.5.0 which looks like it should have the change 😄 |
I believe the fix was developed for |
If there is anything I can help with (including writing code), please let me know, and I'll be happy to contribute in any way I can to help move it forward 😄 |
I've been looking into the code, and adding KubeVersion seems like it would be pretty straight-forward. I've noticed that the automatic discovery of api versions and kubeversion is also only implemented for chart, and not release. This has lead to my confusing situation of importing a release from a running cluster, that now cannot be previewed or upped because the validation assumes a wrong kubeVersion (from local helm install). I think it would make sense to try and align the two, maybe even reuse some common code for the templating in the two cases, to minimize the risk of them diverging in the future? |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
As of pulumi-kubernetes v4.5.4 (#2653), any problem with "chart requires kubeVersion" should be fixed, except in the special case that there's a server connectivity problem, e.g. due to a bad provider configuration. I see no way to pass an explicit |
@EronWright Really nice work! Thank you 😄 |
Hello!
Issue details
#753 explained this issue well, but the resolution does not cover one edge case that we cared about. We have a workflow where we would like to run previews without access to the actual K8s API server (just based on pulumi state which IIUC in the case of helm charts should only use helm template).
#753 (comment) asked for a way to explicitly set
kubeVersion
in the helm args which would have solved our issue as we can explicitly pass this value when running in this semi-offline mode, however the resolution to the previous issue was to auto-derive it from the server which doesn't work in our case. Could akubeVersion
argument still be added to the helm release / chart options to allow explicit override in these cases?Affected area/feature
helm
sdk
The text was updated successfully, but these errors were encountered: