Kubernetes and the order of environment variables

[thrawny]

In a kubernetes manifest you can reference an env variable from another using the $(FOO) notation. However, FOO in this case needs to be defined before it can be referenced.

This causes problems in samson when combining env variables from a yaml file, project and env variable groups. Also of course the ones samson adds, like DEPLOY_GROUP.

As far as I know without having dug deeply into the code, the order is as follows;

• yaml file
• samson (i.e. deploy_group, revision)
• project
• env variable group (in the order they were added for the project?)

So. A project env variable cannot reference an env variable group one and so on. A common case for us that we have an env variable group with some global style variables, like ENVIRONMENT_NAME. And then for a specific project we want to construct an env variable using ENVIRONMENT_NAME. Currently this is impossible without redefining ENVIRONMENT_NAME over and over.
Example:
Project -> SOME_URL: $(ENVIRONMENT_NAME).example.com
Env variable group -> ENVIRONMENT_NAME: foo
The order will be wrong in the kubernetes manifest so the SOME_URL variable will not be interpolated.

Here is a gist showing an example configuration:
https://gist.github.com/esselius/031bdb4d24bc49d77bb4d240c05784a2

My suggestion is that env variables are sorted based on how they are referencing each other, perhaps throwing an error if an impossible situation is encountered. I.e. if two env variables are referencing each other.

I would be happy to make a PR unless someone has a workaround or something that alleviates the need for this.

[grosser]

Easy workaround would be to have the app that uses this url build the url itself with then ENVIRONMENT_NAME env var.

To make the ordering of env variables take into account dependencies would be complex and could cause loops, so I'd prefer to avoid that if possible. Also the current resolution should work just fine unless ENVIRONMENT_NAME itself is referencing another env variable, since the resolution is done after all env variables are merged.

If some kind of parsing is needed though, I think resolve_dollar_variables in plugins/env/app/models/environment_variable.rb could do something like:

• match all used variables
• sort variables by how often they are used
• do the resolution

/cc @zendesk/bre

[grosser]

the problem you are seeing might be that the supported notation is ${FOO} and not $(FOO)

[thrawny]

We were in fact referencing another env variable from ENVIRONMENT_NAME, namely DEPLOY_GROUP. But I don't think it should be too hard to implement a solution that supports arbitrary levels of referencing. Thanks for the input! We might make a PR if the solution does not turn out to be too complex.