There's no way of marking an env configmap or secret as optional

[shawkins]

Description

When using a list property https://quarkus.io/guides/deploying-to-kubernetes#environment-variables-from-secret to associate configmaps or secrets with the env using envFrom, they will always be marked as optional: false

[quarkus-bot[bot]]

/cc @geoand

[shawkins]

As a workaround you can use the src/main/kubernetes/kubernetes.yml fragment, instead of a config property:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-name
spec:
  template:
    spec:
      containers:
      - name: container-name
        envFrom:
        - configMapRef:
            name: map-name
            optional: true

[geoand]

cc @iocanel @metacosm

[metacosm]

Indeed. We could add a configuration option to make the property as optional. I guess we just didn't see the need to it initial since, presumably, when you want to import values, well, you want to import them so they need to be there. 😄 Out of curiosity, could you elaborate on a scenario where you'd need to make that optional? (Not that this impact this feature request in any way, I just want to broaden my horizon on this).

[shawkins]

We are looking at the best way to update the logging configuration at runtime - the configmap where these override values comes from need not exist. We need to have the initial values picked up as configuration in some way - it doesn't have to be environment variables, but while looking at that, I saw the property path doesn't allow setting optional true.

[metacosm]

An option could be to add optional-secrets, optional-configmaps and optionally-mapping configuration entries to generate optional versions of the mappings. What do you think, @shawkins @geoand @iocanel ?

[geoand]

I'm fine with it

[shawkins]

If I understand you correctly, that would look like:

quarkus.kubernetes.env.optional-secrets=x,y,z

quarkus.kubernetes.env.optional-configmaps=a,b,c

quarkus.kubernetes.env.mapping.foo.optional=true

Yes, I'm fine with that.

[metacosm]

Yes for the first two. No for the 3rd one, though that could be an option as well. I was thinking more about quarkus.kubernetes.env.optionally-mapping.foo.[with-key|from-configmap|from-secret] but we certainly could go with quarkus.kubernetes.env.mapping.foo.optionally=true (to keep the "fluency").

[derlin]

no news after one and a half years ? I am looking for this feature as well. I find it very useful when you have defaults, but still want others to be able to override them just by creating a configmap.

[shawkins]

Spent a little looking at what it would take to move this forward. I think decorate needs updated first so Env https://github.com/dekorateio/dekorate/blob/355645046a25d551ca71bf855b88345e601a46ab/core/src/main/java/io/dekorate/kubernetes/annotation/Env.java can be marked as optional. There's several places that would need updated which consume KubernetesEnvBuildItem to build the Env, and the EnvVarsConfig / conversion to KubernetesEnvBuildItem would need to be updated to use optional configmaps / secrets fields. Given the amount of work here and how infrequently it's come up, it seems fine to just rely on the fragment workaround.