Find a better convention referencing env vars in container spec

[concaf]

The current way of referencing other sources for environment variables is like the following -

name: web
replicas: 1
containers:
- image: wordpress:4
  env:
  - name: WORDPRESS_DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: wordpress
        key: DB_PASSWD
  - name: WORDPRESS_DB_NAME
    valueFrom:
      configMapKeyRef:
        key: MYSQL_DATABASE
        name: database

We can establish a convention and replace this with -

name: web
replicas: 1
containers:
- image: wordpress:4
  env:
  - name: WORDPRESS_DB_PASSWORD
    secretRef: wordpress/DB_PASSWD
  - name: WORDPRESS_DB_NAME
    configMapRef: MYSQL_DATABASE/database

To include all data from a given secret/configMap -

name: web
replicas: 1containers:
- image: wordpress:4
  env:
  - name: WORDPRESS_DB_PASSWORD
    secretRef: wordpress/DB_PASSWD
  - name: WORDPRESS_DB_NAME
    configMapRef: MYSQL_DATABASE/database
  - secretRef: secret-certs

[pradeepto]

Do we want to induce string magic?

[concaf]

Do we want to induce string magic?

We didn't disagree to this.

[pradeepto]

I am sure we have always said that string magic is bad many times in the past. And if this syntax is Docker Compose influenced, then we should stay away from it, if possible.

[kadel]

It is not influenced by docker compose.

The question is to find a balance between string magic and adding more levels to yaml file.

[concaf]

@pradeepto -

I am sure we have always said that string magic is bad many times in the past.

Not sure about this, we agreed this with secretRef in OpenCompose, and the way we define ports in OpenCompose (80:8080), is also string magic which is not vanilla Kubernetes spec.

And if this syntax is Docker Compose influenced, then we should stay away from it, if possible.

It's not

[concaf]

ping @surajssd, PTAL

[surajssd]

It was decided that we will add support for envFrom and come back to this later.

[surajssd]

Issue tracking progress of envFrom #43

[pradeepto]

@surajssd @containscafeine Can we close this since we have made a decision?

[concaf]

I think we can keep this open with low or no priority, since we "might" do this sometime if feature requests for this ever drop in. Once we move applications to kedge, if this seems necessary, we might do it then.

[surajssd]

I think we can close this now since this has been taken care of with the field

envFrom

WDYT? @containscafeine

[surajssd]

closing it, since I think the motive of this issue is solved!