Documentation for helmfile DRYness lacks...and maybe not even DRY at all... #2036
Comments
This seems problematic as you're basically throwing away all the environment values defined in those base helmfile configs before calling Maybe what you want would be to dynamically build the environment values to be passed to In contrast, the below doesn't work:
It is complex, I see your frustration, but this is what everyone asked us to do! I hope this clarifies it. Thanks for trying helmfile! |
|
Please also see #762 for the discussion about adding |
|
Okay so I found one more topic in your story.
Helmfile doesn't have a "global" configuration and that limits the level of DRY that Helmfile can achieve. Helmfile tries its best to make each helmfile.yaml independently consumable. It becomes impossible Helmfile had a magical convention to load some global state from a random file in the file hierarchy. So the best thing you can do is to have a single |
|
Trying to complex thing is complex. There isn't magic. If you're going to outgrow what helmfile provides, I'd recommend using more expressive language for compiling helmfile.yaml files and just use helmfile as an executor. A template language like Helmfile template is definitely not a perfect solution for a large-scale work. I've used Helmfile happily for an env with dozens of projects. I had to repeat some I believe our documentation already covers what it can. It's missing information to set a correct expectation, though? I closed this issue as I've answered your questions and this issue itself is too big to be actionable if took as a documentation enhancement request. But if you're really willing to contribute to our documentation, I'd appreciate it if you could create smaller hence more actionable issues, like the one that helps setting a correct expectation on what helmfile can do or not. Thanks. |
|
I appreciate the feedback and assistance @mumoshu. Let me read through these more to grok what you're saying. The more I can grasp more fully the points you're making then the better I can articulate actionable requests and then perhaps even assist in documentation. |
|
@notjames Thanks for confirming! I hope it works for you now and I'm looking forward to your contributions |
|
I think this is where I get lost. The documentation for helmfile indicates a great deal of flexibility, but mostly referentially. That makes sense looking at things from your perspective. From the consumer perspective, it's quite complex and unclear in places. So, the biggest question I have which could clear a lot of FUD for me is how the |
|
@notjames Helmfile splits the target Helmfile executes each part one by one. Execution of each Helmfile part is done by rendering it as a Go template first, and then parsing the render output as a YAML document, converting the YAML document into a Helmfile config. The previous Helmfile config is available to the next part when rendering the Go template. That's why separating |
I had to vent because I'm so frustrated with helmfile.
I'm really struggling to wrap my head around how to implement this project of mine for helmfile. I'm going to try really hard to articulate my problems here, however one of the problems I have with helmfile is the documentation does not do a great job explaining the basics, which I get! This is a project that has developed and changed over time. It's changed and been fixed and features have been added and the documentation is not in just one place...it's all over the place in github issues and I think there are aspects of helmfile which are just not documented at all. These aspects of the tool are where my frustrations seem to come.
Here's my project.
general directory structure
My current directory structure (only directories shown here...no files)
charts directory structure
each directory has its own
helmfile.yamland some contain other necessary files. For instance, chart directories contain respectivevalues.yamlorvalues.yaml.gotmpl,helmfile.yamland such files -- an example of a couple of the charts directories looks like:charts helmfile samples
My charts are broken up into scopes of types of charts under which respective charts exist in their own directories. Let's take a look at a couple of my charts under one of the so-called "tiers" I have set up here...
promtailandkube-prometheus-stackpromtailkube-prometheus-stackenvironment directories and helmfile samples
In order to mildly understand what I have here, it's prudent I give some data into part of the environment directory structure I'm using. The intention is that I run helmfile from any given environment directory such as
test-clusterto set up helm charts for that cluster.starting from
<repo>/environments(the top directory of environments):DRY but not DRY
So one problem I'm running into is that these two examples both require a
bases:object. I tried putting thebases:object contained in ahelmfile.yamlin the parent directory assuming it would/could be inherited because thebases:object is the same for all of my charts. This just didn't work and I had to putbases:object in every. single.helmfile.yamlfor each chart. This is NOT DRY and documentation cannot be found for an actual DRY way to accomplish this. This is just one example. I have many but I'm not able to write them up yet. This should be sufficient for now.global configuration...
So my first attempts at getting something to build was trying to ingest a global manifest for the
test-cluster...which is pulled in from the
bases:object two directories up from thetest-clusterdirectory (see below). When I attempt to build, however, the values in theenv-toggles.yamldoes not propagate to thebases:objectcommon/global-default.env.yaml.gotmplwhich is what consumes the values fromenv-toggles.yaml.I'm not really sure how to solve this. I had to comment out the line to continue test building my project...
More DRY-not-DRY I think
Moving on...
I seem to recall in previous conversations with @mumoshu that since I have separate directories separating out aspects of my project that I have to pass values from the top-most configurations down to the charts or else nothing propagates. As I am refactoring my project today, that seems to likely be the issue into which I'm running?
Given my
test-clusterfrom where I'm runninghelmfile, I have acommon/{repos,versions}.yamlandcommon/global-default.env.yaml.gotmplwhich contains global values and is intended to propagate those values across the project based on environment settings per environment (e.g. test-cluster, cluster1, cluster2, etc)...Now when I run
helmfilewith this setup so far, I expect that my versions will propagate to my charts. However, I get the following error:To sum up...what's happening here is that
helmfilereads myrepos.yamlandversions.yamlmanifests. Theversions.yamlcontains version metadata for all of my charts. When the helmfile build finishes its prelim run through its templates and finally gets to the point where it will build charts, it fails to continue because most if not everything in built is seemingly not available to the charts IE versions (see sample above).I'm not sure what I'm doing wrong here. However, this is exactly what I'm talking about with
helmfile. These kinds of use-cases are not addressed in documentation well enough if at all, as far as I can find. However, I think I have to enter these values in each of thehelmfile.yamlmanifests in each directory to "pass" the values up the chain. I'll test that now and if that works, this is an aspect I've not found in any documentation anywhere. Moreover, it seems an unfortunate requirement if in fact that is what needs to be done to make this work because such causes, in my judgement, this aspect of helmfile to not be DRY.I don't understand the inner-workings of helmfile. My supposition is that it tries to do a LOT under the covers but as such the complexity of how to successfully deploy a large project produces an unfortunate barrier to entry or a more complex project for supporting team engineers to manage because there's seemingly a lot of unintuitive stuff required to make helmfile work as expected.
I've been reading through the following:
I cannot track every single sample, example, question/issue, and documented case in these issues. This is extremely frustrating because I really want to find a solution to this problem..
The text was updated successfully, but these errors were encountered: