Document to put variables into

[ssboisen]

Hi,

This project is looking very interesting, I have been experimenting with kustomize and also felt the need for templating ontop of overlays to edge cases that kustomize didn't cover. I also like the idea of the remove things no longer needed feature of shots.

I were wondering if you had considered having something similar to the kustomization.yaml file in mortar, it would be a nice place to have variables stored and loaded from so you wouldn't need to use command line variables.

That would help with having everything that goes into a deployment in version control.

In addition shot.yaml or whatever you should call it, could contain information similar to those that kustomize supports like imageTags, commonLabels, namespace etc.

Perhaps you feel this is out of scope of mortar or were you invitioning some other way to do these things?

[jnummelin]

in short: yes, we've discussed adding some kind of variables loading mechanism.

Generally, it could always read e.g. shot-vars.yaml (and naturally exclude it from sending to kube api) and parse it to be used as variables. For example, I've got shot-vars.yml as:

foo:
  bar: baz

That would automatically get parsed and I could use var.foo.bar in my templates.

Naturally, those should be also taken up from the overlays and processed in order. so the last overlay could potentially override the base or previous overlays vars.

@ssboisen Would that cover the need for you?

[ssboisen]

sorry for not getting back to you earlier, I think what you proposed would be sufficient but I wonder if it shouldn't be expanded to a more general configuration of mortar so one didn't have to specify overlays on the command line, e.g. I have a production.yaml file that specifies which overlays goes into production as well as variables for that environment?

[jnummelin]

If I get it right, you're looking for something like this as the input "config" for Mortar?

variables:
  foo: bar
  ports:
    - name: dsfsd
      port: 8080
overlays:
  - prod

So say you have this in prod.yml file, then to invoke Mortar with that you'd use something like: mortar -c production.yml my_stack .

[ssboisen]

Yes exactly @jnummelin!

[jnummelin]

Makes sense, and should be pretty doable.

What should happen in case I define variables in both config.yml and using --var? For example:

variables:
  foo: bar

and then I invoke mortar with mortar --var foo=baz, what should the value be for vars.foo in the templates? My initial gut feeling is that --vars should override the vars parsed from config yaml.

[ssboisen]

I would agree with that, input via —var would override the config file. I probably wouldn’t use —var though since my use case for having the file is to store any input to the manifest generation in git for it to be reviewable 😊

[jakolehm]

config.yml probably should also have name: <deployment-name> that can be overridden via parameter?

[jnummelin]

@ssboisen this is now available in 0.3.0-rc1, would be really great if you could give it a test run.