Terraform: Feature request: Helm provider

[devth]

The existing and upcoming Kubernetes additions are great and much needed. In addition to these it would be worth considering a Helm charts provider as a slightly higher abstraction level for working with Kubernetes clusters.

References

• https://github.com/hashicorp/terraform/issues/13420

[stack72]

Hi @devth,

Thanks so much for the request for this new provider!

While we'd love to see something like this, we don't currently have any plans to implement this ourselves. Until then, this issue is unlikely to see any movement and remain stale. We're trying to prune the stale issues (that aren't going to be addressed anytime soon) by closing them. Note that we only do this for enhancement requests and not bugs.

We have future plans to enable community plugins to be available easily from the Terraform binary itself, allowing community members to "ship" plugins with Terraform much easier. There isn't a timeline for this yet but we hope that will allow much easier shipping of both new providers and updates to existing.

Thanks!

@stack72

[mcuadros]

I am starting to work in a helm provider, @stack72 you know if some has starred to work on this?

[stack72]

Not as far as I am aware :)

On Sun, 25 Jun 2017 at 14:59, Máximo Cuadros [e-mail]
wrote:

I am starting to work in a helm provider, @stack72
https://github.com/stack72 you know if some has starred to work on this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/14126#issuecomment-310898658,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN57y2Wl3c54wrdWSdgL-AZFnY8jTDSks5sHku5gaJpZM4NNVrJ
.

[mcuadros]

Ok, I am working on it right now. I wondering witch is the process to publish it under the new provider org?

[stack72]

Open a PR in this repo for now and we can do something about it :)

On Sun, 25 Jun 2017 at 15:45, Máximo Cuadros [e-mail]
wrote:

Ok, I am working on it right now. I wondering witch is the process to
publish it under the new provider org?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/14126#issuecomment-310900641,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN57y2INQsfWpuIWeHcVI5meMsr5oWFks5sHlZ1gaJpZM4NNVrJ
.

[mcuadros]

@stack72 since the provider folder is now empty I don't know where do a PR.

I have a first version where the charts are install, updated and delete properly, with all the config options available at the heml cli.

I have plans to implemente the tiller installation and the repository managament. Besides this and the CI, the main structure is ready.

https://github.com/mcuadros/terraform-provider-helm/tree/master/helm

[stack72]

@mcuadros ok, if you can follow the structure of https://github.com/terraform-providers/terraform-provider-aws

including README, travis, GNUMakefile, docs etc, then we can transfer that repo into the org

We will definitely need to understand how to test this resource before we accept it into the org and, if possible, would like you to be made a maintainer for it

Thoughts?

[mcuadros]

Perfect, I will do it in this way, no problem.
About the testing, I will provide a .travis.yaml with a k8s and helm installed.
I will try to have it ready today.

[stack72]

Rather than adding it to travis file, we will want to set it up in our
TeamCity server for orchestration. So if you can provide a guide on how to
set it up then we can have a look at it :)

On Mon, Jun 26, 2017 at 3:57 PM, Máximo Cuadros [e-mail]
wrote:

Perfect, I will do in this way, no problem.
About the testing, I will provide a .travis.yaml with a k8s and helm
installed.
I will try to have it ready today.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/14126#issuecomment-311051525,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN577qaO92ilEeM5qNj2bU61dHfwJTkks5sH6rLgaJpZM4NNVrJ
.

[mcuadros]

You have in TeamCity the k8s provider running there? Then is just install the helm binary there.

[radeksimko]

We use off-the-shelf GKE to test K8S provider and we stand up & tear down the whole cluster every night: https://github.com/terraform-providers/terraform-provider-kubernetes/blob/master/kubernetes/test-infra/main.tf

There are some long-term plans for having custom K8S environment in AWS & etc., but that's _long-term_ ™️

[mcuadros]

I only need any k8s so GKE is perfectly ok, I can do the test with something like this?

[radeksimko]

As long as you don't need to install anything onto the K8S instances or k8s master (which GKE afaik doesn't allow) then you should be good to go.

[mcuadros]

I need to install the tiller from helm, but I can do the tests atomic. My current tests are being on GKE

[mcuadros]

@stack72 https://github.com/mcuadros/terraform-provider-helm can we transfer it now?
I need to work on the CI and the documentation, where I can see the status TeamCity?

BTW In all the providers, some make rules are broken, should I fix it?

[radeksimko]

can we transfer it now?

@mcuadros AFAIK we don't plan on adding any new providers until 0.10 final is out.

Thanks for the patience.

[pdecat]

Hi there, any update on the plan to relocate https://github.com/mcuadros/terraform-provider-helm to https://github.com/terraform-providers/terraform-provider-helm ?

[dasher]

As 0.10 final is out - can this get moving?

[Quentin-M]

The repository has not been touched since Sep 5 and ownership of the repository is not being transferred (as this issue is inactive). Is this still a thing?

It is very unfortunate because Helm is pretty much widely used in the Kubernetes community nowadays and the 'native' Kubernetes support for Terraform is not making much progress (e.g. core team refuses to get deployment support).

/cc @radeksimko who might not get notifications since the issue has been closed..?

[radeksimko]

👋
the long term plan is to make both user and dev experience for 3rd party providers better. Ideally so good that UX is not a reason for anyone to move provider under the mentioned org.

That said we do have some providers in the queue - practically those who applied through https://www.terraform.io/guides/terraform-provider-development-program.html - those are mainly vendors, but Helm is in the queue too.

Please note that moving a provider under github.com/terraform-providers does not mean that HashiCorp will maintain the provider nor find maintainers for it. The provider already needs to have at least 1 active maintainer who's willing to invest time into it and do so in the future.

We are working actively on recognizing maintenance status of existing providers and find/identify owners for those also. You'll hear some news around that soon.

Will all that said there's nothing (other than sub-optimal UX) preventing you from using the linked Helm provider as a 3rd party providers. It does _not need_ to be under a special org: https://www.terraform.io/docs/plugins/basics.html#installing-a-plugin

[sagikazarmark]

Please note that moving a provider under github.com/terraform-providers does not mean that HashiCorp will maintain the provider nor find maintainers for it.

That's fine, but I believe it's easier to find maintainers if Terraform somehow advocates certain third-party plugins (like the ones that's probably useful for a larger part of the community). It's of course subjective, but still would be nice.

[dabdine-r7]

Trying to understand the reasoning behind a helm provider. IMHO, if the kubernetes provider was augmented enough, there would be no need for a helm provider, because terraform should be able to handle everything helm does. Thus, it would make more sense to double down on the kubernetes provider itself. Am I missing something?

Side note: We use both Terraform and Helm today, but all k8s app management is in helm because of supportability issues. We'd love to move off helm completely and adopt terraform since the majority of our non-k8s infrastructure is there, but that isn't feasible because, as others have said, there are some capability gaps due to the nature of how the k8s tf plugin vs helm work (namely, I can't create deployments or cronjobs using this provider).

[kraney]

The difference between having Terraform manage Kubernetes directly versus having it managing helm is directly analogous to having Terraform install binaries and libraries directly into /usr/bin and /usr/lib versus having Terraform install an RPM or deb package. Either method technically works.

Using the package manager allows

• all of the config plus all pre-install or post-install steps and other little application-specific tweaks to be packaged together neatly
• having them install or fail to install, and later be removed, as an atomic unit
• having dependencies between packages tracked and handled automatically, so if you explicitly want package Z that depends on packages A-Y, you don't have to explicitly install the entire set. You install the thing you want, and it pulls down the other stuff it needs as an implicit operation.

[tomdavidson]

@dabdine-r7 How are you orchestrating the Helm Chart app and non-k8s services?

[bobhenkel]

https://dzone.com/articles/terraform-vs-helm-for-kubernetes

[dabdine-r7]

@tomdavidson By hand, mainly. Luckily for us, the only thing we need to do by hand are "initial deployment" steps, such as creating secrets. We manage IAM accounts & keys with terraform, then manually kubectl create secret... on the command line with that info to feed a helm chart. The ideal, of course, would be to have the terraform kubernetes provider support deployments and secrets, so that we can take advantage of the terraform dependency graph, etc. This hasn't been a huge ordeal, since this type of stuff is really limited to configuration.

[tomdavidson]

Helm has a few technical advantages but I think the real value is in behavior of orgs coalesce on common Chart repos.

[andrewrynhard]

@Quentin-M I have started work on a helm provider: https://github.com/andrewrynhard/terraform-provider-helm/tree/initial-implementation

Aiming to get it into the official org on Github.

[Quentin-M]

@andrewrynhard That's awesome. I'll be sure to keep an eye on it.

[mcuadros]

@Quentin-M https://github.com/mcuadros/terraform-provider-helm is active and supported. What's wrong with it? /cc @andrewrynhard

The provider it's in the queue to be reviewed as an official provider, but this will take some take as discussed with @radeksimko

[andrewrynhard]

@mcuadros While I appreciate the work you have done, we have used it and found it to be very unreliable. Wanting to create resources that already exist, not pick up changes, etc. The latest release completely broke our management of our Helm releases.

There are issues in https://github.com/mcuadros/terraform-provider-helm asking if the project is still active, and with no response. I know we are all busy and contributing is hard when we have a jobs and other priorities. I wanted more immediate results/fixes/features, and didn't feel like it would happen there.

Furthermore, the version of Helm, kubernetes, and Terraform are behind what we use in our clusters. I am hoping to release as new versions of TF, Helm, and Kubernetes are released. I didn't mean to step on any toes 😄 , I simply didn't see a lot of movement or responses to issues/feature requests and decided to create one.

[mcuadros]

As described in the readme, it works with any k8s superior to 1.4 and it's
using the latest client-go.

The issue asking if was maintained or not, was closed after a few days
after it's creation. With several releases after this.

Regarding to versioning and breaking changes, all the current release are
not stable, this what happens when you use 0.x versions.

IMHO creating a new project from scratch and not contributing even with
issues to the existing repository don't help the community.

[sagikazarmark]

@andrewrynhard the issues that turned up in the provider created by @mcuadros prove that this is not an easy topic, so I'm pretty sure sooner or later you will end up having similar issues. We already have one proposed provider to become an official one, it's being tested by the community. That little effort we already put in there will now be split into two.

Maintaining a fork would still be much better than starting another from scratch with a whole new set of issues.

I would really like to see effort placed in making https://github.com/mcuadros/terraform-provider-helm the "official" helm provider.

My two cents.

[gtaylor]

I'd love to have a nice option for TF + Helm, but I don't think there is any TF Helm provider (mcuadros repo or otherwise) that is far enough along for official consideration.

Also: I'm not sure HashiCorp wants to continue accepting just any official providers from the community. It may end up being such that the repos that become ubiquitous in their respective communities eventually get glommed in. In the case of these two particular repos, neither seems to have significant traction.

tldr; Compete, get mindshare, this'll all sort its way out. These both look too preliminary to be made official, IMHO.

[rporres]

@gtaylor Can you elaborate the problems that @mcuadros Helm provider have? It's not extremely useful for the community to just say something is preliminary and not usable and not giving any hint that can help people to improve it. It would even be better if you also reported any issue you've had or any enhancement you're seeking for.

I've been using it for a while and the main problems it had (mostly related to concurrency) are being solved. I find comparing both providers and label both as "preliminary" is utterly unfare as one the providers is usable, is working in production environments, has a history of contributions, has bugs reported and solved and the other has just begun its journey.

[djhaskin987-at-sling]

Of all the parameters to the "helm_release" resource in the provider which @mcuadros has written, only three have an actual "lifecycle" in the terraform sense: "name", "namespace", and the computed "metadata" parameters. The rest of the parameters seem to coincide with options you can use to invoke the helm command line. For example, there is a parameter called "recreate_pods". This is an option to how to invoke helm, yes; but it is not a "part" of a helm chart. You can't run "helm list" to see if it was run with this option.

It seems like the provider was written so that it is easy to declare helm releases, which is great; however, putting parameters into a terraform resource which don't have a lifecycle violates all sorts of assumptions terraform makes about how resources work:

A provider in Terraform is responsible for the lifecycle of a resource: create, read, update, delete.

Writing the provider in this way is, IMHO, a breach of contract with Terraform. It probably leads to the unreliability that @andrewrynhard and @gtaylor refer. For example, the provider in question cannot, now or in the future, support terraform import. (This is a non-starter for us at SlingTV.) I doubt the Terraform core team will be able to support it any time soon, either.

I too have run into the problem that it tries to create releases when they already exist. This would not be a problem if the provider supported terraform import, but after spending hours trawling through the terraform API, it is clear that the resource is simply improperly designed, if easy to use.

Update: If it were not clear from the above, I would LOVE to see a helm provider that correctly manages a helm release. I can see why this may be unreliable, though; there are lots of moving parts -- helm, tiller, terraform. Maybe it would be better to helm template the charts I use and use the raw kubernetes manifest provider, which is simple and works surprisingly well. I'm still looking for solutions to this problem.

Further update: I mean nothing against @mcuadros either. He has put himself out there and done something nice for the community on his own free time. I think it was just a hard case to crack; looking at his code, he calls the helm API the way it is intended to be called. Helm gives us some wins, but I'm starting to feel like maybe if I started another project I should wait for helm 3. It's just hard to create a proper provider with CRUD on it. Helm's API doesn't make this easy.

[djhaskin987]

Within my company I made a helm provider which uses the helm CLI, which I believe will suit my company's needs. I have been given permission to open-source the provider under my own name, and am pleased to provide it to the group represented by this issue in the hopes that it is useful: https://github.com/djhaskin987/terraform-provider-helmcmd

It's not perfect, but I believe will provide a much smoother experience because:

• Use of the helm CLI under the covers makes error messages familiar to those using the CLI
• Strict adherence to the terraform lifecycle concepts within the helm release resource itself
• Support for terraform import
• Using helm upgrade --install for both creation and update of resources

I don't anticipate it getting picked up by the TF core team, as it has external dependencies (the helm CLI), but I hope people will try it out, kick the tires, and find things they don't like about it so that, for those who wish to use the helm CLI provider at least, it can get better.

[luisdavim]

hi, will @mcuadros provider be officially adopted at any point?

[mamoit]

It seems to have been adopted.
https://github.com/terraform-providers/terraform-provider-helm

[mcuadros]

My repository has been moved to terraform-providers org and from now own is going to be maintained by @src-d

So I guess this issue can be "closed" again :P

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.