You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here you can see I've got parameter files for each region I deploy to.
Often, the configuration is the same for configurable values in lots of regions with a few slight differences. What I'd like to be able to do is have parameter inheritence through a directory tree, in a similar manner to hiera
How might this look in practice? Well, you'd have a directory structure like this:
The input parameters from the command line are merged from left to right so you can do:
jk generate -f defaults.yaml -f regions/us-west-2.yaml ...
and the values of the regional file are merged into the default values.
The rules for this merging are fixed: objects are deep merged but other values (arrays and primitive values) are taken from the right most file.
If you need more, we have now std/merge that can do arbitrary merging: you supply functions to merge the right and left objects/arrays/values. For instance, if you want to merge arrays by taking elements from both sides but ensuring the merge has unique elements, you can just provide the function that does that to merge.
I'll come up with examples in the next few days, I'd like to start writing examples for questions that arise :)
@dlespiau don't see a way to supply a merge function to either jk run or jk generate. Do you mean we need to read the files on our own and use std/merge ?
More of a feature request, maybe this is already possible but maybe not.
I use jk pretty heavily for regional deployments and the ability to set parameters for the regional deployments. As an example:
Here you can see I've got parameter files for each region I deploy to.
Often, the configuration is the same for configurable values in lots of regions with a few slight differences. What I'd like to be able to do is have parameter inheritence through a directory tree, in a similar manner to hiera
How might this look in practice? Well, you'd have a directory structure like this:
Then, as an example, we'd have parameters in
defaults.yaml
like so:If the value existed lower down the hierarchy (for example, in
regions/us-west-2.yaml
it would be the preferred loaded parameter:If this value doesn't exist, it falls back to the default parameters in
defaults.yaml
.I imagine this would be another params function, let's say:
The text was updated successfully, but these errors were encountered: