-
Notifications
You must be signed in to change notification settings - Fork 115
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
Initial support for Helm release resource #1677
Conversation
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
We're expecting to have it available as a beta/dev preview resource soon. I'll say end of September conservatively, but likely sooner than that. |
Levi, my understanding is that this should be available by early September. Is that right? cc @lukehoban |
@joeduffy Yes, AFAIK. I need to confirm with Vivek, but I believe we're just about ready to ship initial support (minus the list of followup items in the description). |
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
@@ -70,6 +70,30 @@ func PulumiSchema(swagger map[string]interface{}) pschema.PackageSpec { | |||
Description: "If present and set to true, suppress apiVersion deprecation warnings from the CLI.\n\nThis config can be specified in the following ways, using this precedence:\n1. This `suppressDeprecationWarnings` parameter.\n2. The `PULUMI_K8S_SUPPRESS_DEPRECATION_WARNINGS` environment variable.", | |||
TypeSpec: pschema.TypeSpec{Type: "boolean"}, | |||
}, | |||
"suppressHelmReleaseBetaWarning": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would make sense to nest these helm-specific configs under a top-level config to avoid cluttering the docs + auto-complete suggestions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will play with this. I can follow up for this in a separate PR?
if k.defaultNamespace != "" { | ||
namespace = k.defaultNamespace | ||
} | ||
k.helmReleaseProvider, err = newHelmReleaseProvider( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how much overhead this causes, but we might want to make this conditional on the program using a helm Release resource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Though this should be fairly lightweight for the moment. Happy to revisit later.
if !k.clusterUnreachable { | ||
return k.helmReleaseProvider.Check(ctx, req, !k.suppressHelmReleaseBetaWarning) | ||
} | ||
return nil, fmt.Errorf("can't use Helm Release with unreachable cluster. Reason: %q", k.clusterUnreachableReason) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should print some sort of placeholder value rather than erroring in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is desirable to render the manifests and resource names from the helm release but they would only render if I emitted them from Check (and not from Create/Update etc.). As a result Check is an "online"-only operation at the moment. I am happy to open an issue to revisit this. Perhaps we can mark those fields as computed instead when the cluster is unreachable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it seems like we should be able to fall back to showing some minimal info rather than erroring. Two things to check here would be YAML render mode, which generally doesn't require an active cluster, and the case where the cluster hasn't been created yet, but is a parent in the stack via the Provider.
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good as a starting point for the beta. 👍
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
Does the PR have any schema changes?Looking good! No breaking changes found. New resources:
|
|
hi, as this was blocking us to use pulumi for our helm releases and it got merged now for beta, how am i able to use and test this version? what version tag do i have to specify in my |
@muhlba91 I am planning to cut a release today and will update this issue with directions. Thanks for your patience! |
@viveklak does the current implementation support installing charts from local files like the |
This change adds a new resource -
kubernetes:helm.sh/v3:Release
. This resource directly utilizes Helm to orchestrate the installation of charts into releases. Users can query the release through Pulumi as well as Helm.This is heavily inspired by https://github.com/hashicorp/terraform-provider-helm fashioned for Pulumi's kubernetes provider.
Here is an example of the experience so far:
With the default behavior (
skipAwait = false
) all resources must be available before the release becomes available and the subsequentget
on the service works. Note that underlying resources are not in state (unlike helm chart support).How to build/use
export PATH=$PATH:$PWD/bin
Things to do:
The following are known follow-up items which have corresponding issues being tracked: