[Feature] Support environment variables

[Alex Ellis]

Inspired by the Kubernetes spec, support environment variables.

I think run-job should remain as simple as possible, but these are normally required for many kinds of container.

K8s format

    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"
    - name: DEMO_FAREWELL
      value: "Such a sweet sorrow"

I'd be tempted to use the OpenFaaS format, but the K8s style may be easier for people migrating tasks.

environment:
  DEMO_FAREWELL: "Such a sweet sorrow"

By running the env built-in shell command in alpine:3.16, we can see whether the inputs have been received.

[Maria Kotliarevskaia]

Hey. I would suggest to stick with Kubernetes specification because some people may want to do the following

kubectl get -oyaml job curl > job.yaml
run-job -f job.yaml

To do so seamlessly, it requires to be fully compatible with K8S spec.

[Alex Ellis]

Hi @Jasstkn

This specifically will not work as expected, because the YAML format is different and much simpler:

kubectl get -oyaml job curl > job.yaml
run-job -f job.yaml

But they could do kubectl get -o yaml then copy/paste in the "env" section.

Would you like to add support for environment variables using the env format from the above?

[Maria Kotliarevskaia]

Hi @Jasstkn

This specifically will not work as expected, because the YAML format is different and much simpler:

kubectl get -oyaml job curl > job.yaml
run-job -f job.yaml

But they could do kubectl get -o yaml then copy/paste in the "env" section.

Would you like to add support for environment variables using the env format from the above?

Ah, yes, you're right! Yep, I would like to implement this feature as well.

[Michael]

Would be great to have support for this & envFrom. One of my use cases for run-job would be to run Flyway for SQL database migrations, and it would be nice to use envFrom to read from an existing secret.

[Alex Ellis]

@clrxbl what data do you need for your envFrom use-cases?

If it's for secrets, we would also need to add secret support.

In OpenFaaS we do this by convention. Specify a list of secret names with secrets: and then the data is mounted in a projected volume under /var/openfaas/secrets/NAME/

That makes them quite convenient to read in bash / code.

[Michael]

@clrxbl what data do you need for your envFrom use-cases?

I simply use envFrom to read from a single Secret containing environment variables for e.g. database authentication.

[Alex Ellis]

Secret support seems reasonable for connecting to databases/APIs etc.

faas-cli list/describe etc instance also require faas-cli login first.

[Maria Kotliarevskaia]

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?

FYI @alexellis

[Michael]

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?

FYI @alexellis

It would be great to have it use the same approach as in the Kubernetes Job manifest as it allows you to refer to environment variables located in secrets.

[Maria Kotliarevskaia]

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?
FYI @alexellis

It would be great to have it use the same approach as in the Kubernetes Job manifest as it allows you to refer to environment variables located in secrets.

You can take a look how I implemented it in the PR: #7 and also our discussion with @alexellis about possible improvements there: #7 (comment). I'm not sure which one is better.

[Michael]

@clrxbl hello. We are in the discussion of what is the best way to implement this feature. Could you tell me what you feel is more convenient for you: the same approach as in the Kubernetes Job manifest or a more compact way with just a bare minimum and all parsing done under the hood?
FYI @alexellis

It would be great to have it use the same approach as in the Kubernetes Job manifest as it allows you to refer to environment variables located in secrets.

You can take a look how I implemented it in the PR: #7 and also our discussion with @alexellis about possible improvements there: #7 (comment). I'm not sure which one is better.

Looking at #7
IMO, it would be better to stick to how Kubernetes' formatting does it currently with env & envFrom.

[Alex Ellis]

Could you give an example of how you think the YAML would look?

[Michael]

Could you give an example of how you think the YAML would look?

name: checker
image: ghcr.io/openfaas/config-checker:latest
namespace: openfaas
sa: openfaas-checker
env:
  - name: "KEY"
    value: "value"
envFrom:
  - secretRef:
      name: "secret-name"

[Maria Kotliarevskaia]

@alexellis hey. what do you think about the example above?