[FEATURE]: use valueFrom in container type env section

[wojtkowiak]

Feature Request

Would it be possible to use the valueFrom the same way secretRef is currently supported?

valueFrom:
  fieldRef:
    fieldPath: spec.nodeName

Background / Motivation

So I am just starting with garden and I may be very wrong here but because I need the nodeName passed into an env I will not be able to use the simplicity of type: container and will have to still keep my stuff in kubernetes yml which is a bummer 🙂
I actually spent like 40 minutes wondering why it is not working because seeing the secretRef being used in an example I just conjectured I can use any other directives I would normally be able to use in k8 yml

What should the user be able to do?

services:
  - env:
        - MY_VAR: some-value
          MY_OTHER_VAR:
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName

Why do they want to do this? What problem does it solve?

described in motivation section above

Suggested Implementation(s)

described above

How important is this feature for you/your team?

🌵 Not having this feature makes using Garden painful - exaggerating here but it ruined the excitement for a moment 🙂

[eysi09]

Hi @wojtkowiak and thanks for opening this issue!

The container module type isn't really aware of Kubernetes and could conceptually be deployed by other providers as well. That's why we're vary of adding Kubernetes specific fields that don't translate to other potential platforms.

I'm assuming the node names are dynamic and you simply don't want to go for MY_OTHER_VAR: my-node-name.

If you're using Terraform to provision your infrastructure, you could read the value from the Terraform outputs. Something like:

MY_OTHER_VAR: "${runtime.services.my-terraform-service.outputs.node-name}"

Another solution would be to use a task that could read the node name and reference that at the service level. Like:

services:
  - env:
        - MY_VAR: some-value
          MY_OTHER_VAR: "${runtime.tasks.read-node-name.outputs.log}"
tasks:
  - name: read-node-name
     command:  # Add command...
     args: # ...and args for reading the nodename

And finally, if you want to run the task locally as opposed to from within the cluster, you can wrap it in a local exec module:

services:
  - env:
        - MY_VAR: some-value
          MY_OTHER_VAR: "${runtime.tasks.read-node-name.outputs.log}"
# Rest of module config...

---

kind: Module
name: node-name-reader
type: exec
local: true
tasks:
  - name: read-node-name
     command:  ["kubectl", "get", "nodes", "..."] <--- This runs locally

Would any of these help your use case?

[edvald]

There is another idea... We can include some of these common metadata fields automatically when generating the Deployment from container modules. I'll push a PR for that shortly, which among others sets POD_NODE_NAME to the spec.nodeName value. @wojtkowiak any other values that you could imagine being useful?

[wojtkowiak]

@eysi09 sorry for late response, I was going to try your ideas this week but seems that @edvald solved my problem. Anyway your ideas gave me a hint to solve another problem I had so thanks anyway!

@edvald thank you very much, your PR covers all I ever needed!