Feature Request/Discussion: Remote Helmfiles? #347
Comments
|
@mumoshu it's not urgent at this time. We'd use it if it were there, but we are not blocked by it. |
|
@osterman Noted 👍 Thanks. |
|
Hi, I like the idea of remote helmfiles. These helmfiles can be stored on a remote git repo, and we can point to a specific tag version of the config. Waiting for remote helmfile support, I am doing this workaround: values.yaml: helmfile: |
|
@johnmarcou Awesome workaround! Yeah, this feature gets more interesting as we added One thing I'm missing before going forwad is that we still miss a kind of #195. That is, remote But there's no way to distribute "common" values.yaml or even shell scripts that is referenced from the Any thoughts? |
|
To be explicit, I'd like to introduce my use case here. I want to deploy N charts on M clusters to deploy cluster addons (logging, monitoring, ingress). To avoid to rewrite or copy/past the config for each cluster, I use Inspired by Terraform and its module feature, we would do:
For example: With helmfile, we can apply the same logic.
===
For module data, I see two implementations: For the injected data, I see two implementations: I am using a, c, d and d' so far, depends of the nature of the config. |
|
I guess your main point is about b. Terraform has the same problematic: load a file from the caller or from the module? https://www.terraform.io/docs/configuration-0-11/interpolation.html#file-path- An (ugly?) way to implement that would be: With Again, Terraform doesn't need remote assets path resolving since everything is git-cloned locally during the init. |
|
Also related: #469 |
|
#195 is interesting and might simplify this ask. Perhaps helmfiles with their values ought to be thought of as packages, although that's not a requirement for us. The simple interface of just supporting a list of URLs would work wonders for us as we don't have the same requirements maybe as others. |
I'm soooo glad to see you had the same concern with me! I'm reading through your whole comment now... |
I didn't feel your idea of I might be still missing something, but anyway - I was just thinking about making helmfile (1)
Perhaps my above idea aligns with how terraform's handling modules, especially in the part With it, @osterman's example: will end up helmfile git-cloning the
respectively.
This would work as before.
Yep. This works for For
Great! I think this works as before even after the above enhancement.
I couldn't understand this - How does the module helmfile discover
Awesome. I think you've almost given us the solution I couldn't come up 👍 |
@johnmarcou What made you think it may be ugly? Was it related to the syntax, or anything else? |
|
@mumoshu I think you're on to something!! I think what you are proposing sounds quite familiar to What this says is to clone This can support private repos using (a) ssh or (b) using |
|
@osterman Thanks for confirming!
Yeah. I think this is an important part. |
This change enhances helmfile to accept terraform-module-like URLs in nested state files a.k.a sub-helmfiles. ```yaml helmfiles: - # Terraform-module-like URL for importing a remote directory and use a file in it as a nested-state file # The nested-state file is locally checked-out along with the remote directory containing it. # Therefore all the local paths in the file are resolved relative to the file path: git::https://github.com/cloudposse/helmfiles.git@releases/kiam.yaml?ref=0.40.0 ``` The URL isn't equivalent to terraform module sources. The difference is that we use `@` to distinguish between (1) the path to the repository and directory containing the state file and (2) the path to the state file being loaded. This distinction provides us enough fleibiity to instruct helmfile to check-out necessary and sufficient directory to make the state file works. Resolves #347
This change enhances helmfile to accept terraform-module-like URLs in nested state files a.k.a sub-helmfiles. ```yaml helmfiles: - # Terraform-module-like URL for importing a remote directory and use a file in it as a nested-state file # The nested-state file is locally checked-out along with the remote directory containing it. # Therefore all the local paths in the file are resolved relative to the file path: git::https://github.com/cloudposse/helmfiles.git@releases/kiam.yaml?ref=0.40.0 ``` The URL isn't equivalent to terraform module sources. The difference is that we use `@` to distinguish between (1) the path to the repository and directory containing the state file and (2) the path to the state file being loaded. This distinction provides us enough fleibiity to instruct helmfile to check-out necessary and sufficient directory to make the state file works. Under the hood, it uses [hashicorp/go-getter](https://github.com/hashicorp/go-getter), that is used for [terraform module sources](https://www.terraform.io/docs/modules/sources.html) as well. Only the git provider without authentication like git-credentials helper is tested. But theoretically go-getter providers should work. Please feel free to test the provider of your choice and contribute documentation or instruction to use it :) Resolves #347
This change enhances helmfile to accept terraform-module-like URLs in nested state files a.k.a sub-helmfiles. ```yaml helmfiles: - # Terraform-module-like URL for importing a remote directory and use a file in it as a nested-state file # The nested-state file is locally checked-out along with the remote directory containing it. # Therefore all the local paths in the file are resolved relative to the file path: git::https://github.com/cloudposse/helmfiles.git@releases/kiam.yaml?ref=0.40.0 ``` The URL isn't equivalent to terraform module sources. The difference is that we use `@` to distinguish between (1) the path to the repository and directory containing the state file and (2) the path to the state file being loaded. This distinction provides us enough fleibiity to instruct helmfile to check-out necessary and sufficient directory to make the state file works. Under the hood, it uses [hashicorp/go-getter](https://github.com/hashicorp/go-getter), that is used for [terraform module sources](https://www.terraform.io/docs/modules/sources.html) as well. Only the git provider without authentication like git-credentials helper is tested. But theoretically go-getter providers should work. Please feel free to test the provider of your choice and contribute documentation or instruction to use it :) Resolves #347
This change enhances helmfile to accept terraform-module-like URLs in nested state files a.k.a sub-helmfiles. ```yaml helmfiles: - # Terraform-module-like URL for importing a remote directory and use a file in it as a nested-state file # The nested-state file is locally checked-out along with the remote directory containing it. # Therefore all the local paths in the file are resolved relative to the file path: git::https://github.com/cloudposse/helmfiles.git@releases/kiam.yaml?ref=0.40.0 ``` The URL isn't equivalent to terraform module sources. The difference is that we use `@` to distinguish between (1) the path to the repository and directory containing the state file and (2) the path to the state file being loaded. This distinction provides us enough fleibiity to instruct helmfile to check-out necessary and sufficient directory to make the state file works. Under the hood, it uses [hashicorp/go-getter](https://github.com/hashicorp/go-getter), that is used for [terraform module sources](https://www.terraform.io/docs/modules/sources.html) as well. Only the git provider without authentication like git-credentials helper is tested. But theoretically any go-getter providers should work. Please feel free to test the provider of your choice and contribute documentation or instruction to use it :) Resolves #347
This change enhances helmfile to accept terraform-module-like URLs in nested state files a.k.a sub-helmfiles. ```yaml helmfiles: - # Terraform-module-like URL for importing a remote directory and use a file in it as a nested-state file # The nested-state file is locally checked-out along with the remote directory containing it. # Therefore all the local paths in the file are resolved relative to the file path: git::https://github.com/cloudposse/helmfiles.git@releases/kiam.yaml?ref=0.40.0 ``` The URL isn't equivalent to terraform module sources. The difference is that we use `@` to distinguish between (1) the path to the repository and directory containing the state file and (2) the path to the state file being loaded. This distinction provides us enough fleibiity to instruct helmfile to check-out necessary and sufficient directory to make the state file works. Under the hood, it uses [hashicorp/go-getter](https://github.com/hashicorp/go-getter), that is used for [terraform module sources](https://www.terraform.io/docs/modules/sources.html) as well. Only the git provider without authentication like git-credentials helper is tested. But theoretically any go-getter providers should work. Please feel free to test the provider of your choice and contribute documentation or instruction to use it :) Resolves #347
|
This feature is implemented for The helmfile module cache is currently hard-coded to something like Ideas for further feature requests:
|
|
Hi @mumoshu
I was thinking about a function which take a URL from the sub-helmfile to rewrite/generate the url on the assets, from that URL. I feel it ugly since all git providers doesn't use the same way/structure to provide access to the raw version of the assets. For example:
So it would be hard to have a consistent function for that. But if helmfile is using git clone to have the sub-helmfile (assets included) locally, it sounds really good to me.
Regarding the config propagation, I would say there is 2 different needs: 1 - helmfile module ( 2 - sub-helmfile ( Let's take that example: If we set My opinion is it should result as In practice, for example, myenvval could be a SlackChannel value: |
|
@johnmarcou Thanks for the response!
Glad you liked it :) To be extra clear, that's how #648 has been implemented.
I believe it's a valid use-case. One thing I'm not decided yet is that how we should pass values to the module(I call it a "layer" or a "base" btw). The current helmfiles:
- path: path/to/sub/helmfile.yaml #or go-getter url
values:
- key1: val1
- overrides.yamlI'm wondering if it's ok to change bases:
- path: path/to/module.yaml
values:
- key1: val1
- overrides.yaml # all these overrides are available via e.g. {{ .Values.key1 }} within the module.yamlDoes that sound good to you? |
|
That sound's absolutely perfect to me. Environment values should be propagated from parent to child (the closest wins) and use as ... env values as it was the initial purpose. I look forward to see that features happen! Thank you for that. |
|
@johnmarcou To be extra clear, I'm assuming in #347 (comment) |
|
It really depend on how/where you set values but:
means that your example must be rewritten as follows to propagate values at all: And for And the "cloest" one wins when no values are passed explicitly: The "cloest" one wins also when no values are passed explicitly for |
|
@bitsofinfo Sharing this thread with you, as I believe you're the biggest user of TL;DR; I'm making a breaking change on |
|
for what im doing now, will there be a workaround? can read this right at the moment but what changes? so what you mean is if one "base" declares a |
Yes. Helmfile is already working as such for that point, and remains so.
Values will not be inherited implicitly after the proposed change.
You'll be able to pass values explicitly from the parent by: So that in Or you can specifically instruct helmfile to inherit values like this: So that in |
|
ok, so from what I can tell, it should all keep working, especially w/ that |
|
@bitsofinfo Great! Thanks for confirming. |
what
why
use-case
We write a lot of helmfiles used by different organizations. We version pin to a release of our helmfiles distribution, however, sometimes users need to update only one specific service and are not ready to upgrade all services in a given release of helmfiles.
Using the approach above works more like
terraformmodules empowering the user to surgically import resources into their environment, while keeping it DRY and CODEOWNERS friendly by using a single source of truth.references
helmfiles: <ordered glob patterns of helmfiles>configuration #266The text was updated successfully, but these errors were encountered: