Kubernetes env vars generation changed unexpectedly

[Ladicek]

Describe the bug
I have these lines in my application.properties:

quarkus.openshift.env-vars.DB_DATABASE.secret=postgresql
quarkus.openshift.env-vars.DB_DATABASE.value=database

And I expect Quarkus Kubernetes to generate an env var that corresponds to the database field of the postgresql secret. This is how it works in Quarkus 1.3.3, at least:

        - name: "DB_DATABASE"
          valueFrom:
            secretKeyRef:
              key: "database"
              name: "postgresql"
              optional: false

However, when trying on Quarkus 1.5.0.CR1, I only get this:

        - name: "DB_DATABASE"
          value: "database"

Expected behavior
See above.

Actual behavior
See above.

To Reproduce
Steps to reproduce the behavior:

1. Add quarkus-openshift.
2. Add configuration per above to application.properties.
3. mvn clean package
4. See target/kubernetes/openshift.yml

Configuration
See above.

Environment (please complete the following information):

• Output of uname -a or ver:

  lthon@argondie:~$ uname -a
  Linux argondie 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
  

• Output of java -version:

  lthon@argondie:~$ java -version
  openjdk version "1.8.0_252"
  OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~18.04-b09)
  OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
  

• GraalVM version (if different from Java): N/A
• Quarkus version or git rev: 1.5.0.CR1
• Build tool (ie. output of mvnw --version or gradlew --version):

  lthon@argondie:~$ mvn --version
  Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
  Maven home: /home/lthon/software/apache-maven
  Java version: 1.8.0_252, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre
  Default locale: cs_CZ, platform encoding: UTF-8
  OS name: "linux", version: "4.15.0-101-generic", arch: "amd64", family: "unix"
  

Additional context
See also https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Kubernetes.20env.20vars

[Ladicek]

CC @geoand @iocanel

[geoand]

Also cc @metacosm

[metacosm]

I will take a look ASAP.

[iocanel]

CC @geoand @iocanel

Hmmm, I didn't realize this used to work. In fact I was about ti implement it now.

[metacosm]

Yes, I'm surprised that that was the previous behavior because I didn't encounter it in my testing and it definitely isn't / wasn't documented.

…

On Wed, May 27, 2020 at 12:59 PM Ioannis Canellos ***@***.***> wrote: CC @geoand <https://github.com/geoand> @iocanel <https://github.com/iocanel> Hmmm, I didn't realize this used to work. In fact I was about ti implement it now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9629 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5J6JACEQ2CBEPKEMMJPDRTTW67ANCNFSM4NL7MQ5A> .

[Ladicek]

I'm fine with the old syntax not working, if there's a replacement and migration documentation.

In fact, just today I've learnt (in the linked Zulip topic) that there's a new syntax for env vars coming in 1.5 (a82951f), but there's nothing in the 1.5 migration guide.

[iocanel]

In the new syntax we need to implement support for something like:

quarkus.kubernetes.secret.SECRET_NAME.secret-key=SECRET_KEY
quarkus.kubernetes.secret.SECRET_NAME.name=ENV_VAR_NAME

AFAIR, @metacosm expressed the desire to work on this issue, so I'll assign it to him.

[Ladicek]

I will repeat that until someone acks -- we need the migration guide content!

[metacosm]

I will repeat that until someone acks -- we need the migration guide content!

That said, the old syntax should still be working for the time being.

[Ladicek]

I think I have clearly demonstrated that some of it does not :-)

[metacosm]

I think I have clearly demonstrated that some of it does not :-)

Yep, but the intent is to remedy to this situation :)

[metacosm]

I've completed the first pass on a fix in the #9758 PR and added support for defining vars from secret/configmap keys using the following syntax:

quarkus.kubernetes.env.vars-from-secret.foo.key=keyName
quarkus.kubernetes.env.vars-from-secret.foo.secret=secretName

which would create the following:

env:
  - name: FOO
     valueFrom: 
        secretKeyRef:
          key: keyName
          name: secretName
         optional: false

and would be equivalent to the previous syntax:

quarkus.kubernetes.env-vars.foo.secret=secretName
quarkus.kubernetes.env-vars.foo.value=keyName

Let me know what you think, @Ladicek @iocanel, please.

[Ladicek]

That looks good to me.

[metacosm]

For reference, the new syntax is:

quarkus.kubernetes.env.mapping.foo.with-key=keyName
quarkus.kubernetes.env.mapping.foo.from-secret=secretName

since that was changed during the PR review process.