quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.59k stars 2.63k forks source link

Kubernetes: inconsistent handling of kubernetes.name/group/version properties #6726

Closed Ladicek closed 4 years ago

Ladicek commented 4 years ago

Describe the bug

I'm using the kubernetes extension to generate Kubernetes and OpenShift resources, and find that the kubernetes.name/group/version configuration properties are handled wildly inconsistently.

The problem seems to be in Dekorate, but the KubernetesProcessor in Quarkus is also involved (it sets the app.group system property). I think the root cause is that the Dekorate Resources object, which is shared among the entire Dekorate Session, is being modified in the middle of Dekorate processing (by the callers of AbstractKubernetesHandler.setApplicationInfo).

Here's my application.properties file:

quarkus.application.name=test
kubernetes.name=foo
kubernetes.group=bar
kubernetes.version=my1.0version
kubernetes.expose=true

And the generated kubernetes.yml; marking the relevant lines by !!!:

---
apiVersion: "v1"
kind: "ServiceAccount"
metadata:
  labels:
    app: "test" # !!!
    version: "1.0.0-SNAPSHOT" # !!!
    group: "bar" # !!!
  name: "foo" # !!!
---
apiVersion: "v1"
kind: "Service"
metadata:
  labels:
    app: "test" # !!!
    version: "1.0.0-SNAPSHOT" # !!!
    group: "bar" # !!!
  name: "foo" # !!!
spec:
  ports:
  - name: "http"
    port: 8080
    targetPort: 8080
  selector:
    app: "foo" # !!!
    version: "my1.0version" # !!!
    group: "bar" # !!!
  type: "ClusterIP"
---
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  labels:
    app: "foo" # !!!
    version: "my1.0version" # !!!
    group: "bar" # !!!
  name: "foo" # !!!
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "foo" # !!!
      version: "my1.0version" # !!!
      group: "bar" # !!!
  template:
    metadata:
      labels:
        app: "foo" # !!!
        version: "my1.0version" # !!!
        group: "bar" # !!!
    spec:
      containers:
      - env:
        - name: "KUBERNETES_NAMESPACE"
          valueFrom:
            fieldRef:
              fieldPath: "metadata.namespace"
        image: "bar/test:1.0.0-SNAPSHOT" # !!!
        imagePullPolicy: "IfNotPresent"
        name: "foo" # !!!
        ports:
        - containerPort: 8080
          name: "http"
          protocol: "TCP"
---
apiVersion: "extensions/v1beta1"
kind: "Ingress"
metadata:
  labels:
    app: "test" # !!!
    version: "1.0.0-SNAPSHOT" # !!!
    group: "bar" # !!!
  name: "foo" # !!!
spec:
  rules:
  - host: ""
    http:
      paths:
      - backend:
          serviceName: "foo" # !!!
          servicePort: 8080
        path: "/"

Expected behavior

I'd expect kubernetes.name to have priority over quarkus.application.name, but I see that sometimes it's one and sometimes it's the other.

The kubernetes.group setting seems to be set consistently. But if I rename it to openshift.group, it still affects the Kubernetes resources, which sounds wrong.

I'd expect kubernetes.version to have priority over what Dekorate reads from pom.xml, but I see that sometimes it's one and sometimes it's the other.

Actual behavior

See above.

Also I think that kubernetes.* properties should only affect Kubernetes resources, openshift.* properties should only affect OpenShift resources, etc. This seems to be the case for 99% of properties, the only problematic ones are potentially the name, group and version things. This seems to be because Dekorate expects these properties to be always the same (app.name/group/version). I'd be fine with keeping them always the same, too, but then there should be no openshift.name/group/version or knative.name/group/version. (Preferrably, there would be no kubernetes.name/group/version and it would be centralized under quarkus.application, in my opinion.)

To Reproduce Steps to reproduce the behavior:

  1. Generate a simple application with the kubernetes extension
  2. Use the application.properties per above
  3. mvn clean package
  4. See target/kubernetes/kubernetes.yml

Environment (please complete the following information):

$ uname -a
Linux argondie 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-8u232-b09-0ubuntu1~18.04.1-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
Ladicek commented 4 years ago

CC @iocanel

geoand commented 4 years ago

@iocanel I assume you will be handling this one?

iocanel commented 4 years ago

I think that we have multiple issues here.

The first task is probably a dekorate issue. The other two are possibly something we deal with in KubernetesProcessor.

@Ladicek: I am not sure what's the intention here. Do you want me to pick this issue up? Is this something you were planning to work on?

Ladicek commented 4 years ago

@iocanel I played with this a bit yesterday and it doesn't seem like an easy fix, due to all the mutability inside Dekorate. My current assignment is to find bugs, not fix them, so if you could take this, that would be great :-)

rsvoboda commented 4 years ago

@Ladicek can you double check if this issue is still valid ?

rsvoboda commented 4 years ago

@Ladicek re-ping

Ladicek commented 4 years ago

Ah, totally missed this one. Will check.

Ladicek commented 4 years ago

This works fine now, closing. Thanks!