Environment configuration from Jsonnet

[Mikulas]

Hi! I find spec.json somewhat unwieldy. Would you be open to reading the spec from the evaluated jsonnet? What I mean is pkg/tanka.eval could theoretically be updated like this

 func eval(dir string, opts jsonnet.Opts) (raw interface{}, env *v1alpha1.Config, err error) {
    …
    env, err = parseSpec(baseDir, rootDir)
    if err != nil {…}

    raw, err = evalJsonnet(baseDir, env, opts)
    if err != nil {…}

+   env, err = readConfigFromEvaluatedJsonnet(raw, env)
+   if err != nil {…}

    return raw, env, nil
 }

Where readConfigFromEvaluatedJsonnet would filter raw for v1alpha1/Environment objects and updating env.

This would present some issues with reading the config from tk.env, though that may (or may not?) be resolved with late binding. Besides that I don't see other compatibility issues.

Ideally this would allow for this:

main.jsonnet

local mylib = (import "mylib.libsonnet");

mylib.appGenerator("some config") + {
    env: {
      "apiVersion": "v1alpha1",
      "kind": "Environment",
      "metadata": {
        "name": "my-env-name"
      },
      "spec": {
        "namespace": "my-namespace"
      }
    }
}

This could eventually simplify the codebase by removing the tk.env altogether. Furthermore it could remove the arbitrary file spec.json.
Is this a change that would be interesting to you at all? If so, I would prepare a proof of concept.

[issue-label-bot]

Issue-Label Bot is automatically applying the label kind/question to this issue, with a confidence of 0.67. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[malcolmholmes]

@Duologic ^^^

[Duologic]

We've been discussing several ideas on how to handle spec.json better.
I'm personally on favor of feeding a tanka.dev/v1alpha1/Environment as a top level object into Tanka, that object could have a data: (import 'main.jsonnet') to read all the Kubernetes objects from.
Compared to how it works now (environment directories), this would allow for a file based approach, more fine-grained control and less boiler plate. A single main.jsonnet could be sourced in multiple environments, without all the directory bootstrapping.
Also we've been discussing supporting more than Kubernetes, for example Terraform or Ansible, which would be another top level object (tanka.dev/v1alpha1/Terraform) in this idea.
These are all very fundamental and fresh ideas, so don't expect them to happen overnight. 🙈

[Mikulas]

Oh that sounds brilliant! Top level tanka.dev/v1alpha1/Environment as an extension of v1/List makes a lot of sense. And it is arguably more generic than the original suggestion which is great.

I see where you are coming from with the different targets/engines. Not something I personally would have a use for at the moment, but aiming for a more universal tool is reasonable (which is imo something kustomize failed to do 😇).

Thank you for discussing this with me. As the original question was answered, feel free to close this ticket.

[sh0rez]

I support this change. As @Duologic already outlined, this is part of ongoing design discussions around broadening the amount of systems Tanka manages, however this might look in the end.

It is very reasonable to read our runtime configuration from the more powerful configuration language after all.

I'll keepalive this issue, and if implemented or otherwise addressed :)

[Duologic]

@Mikulas You might be interested in the next community call, @sh0rez is that call published somewhere public?

[sh0rez]

#392
^^ Link in there

[rrichardson]

I would be for any solution that lets me deploy to an arbitrary namespace. If there is a plan for this, I would be happy to help implement it.

[Duologic]

Inline environments is available in v0.13.0, does this resolve your question? If not, please open a separate issue.

[Duologic]

@Mikulas thank you for your input, as stated above, the Environment config can now be used in Jsonnet.