Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes name influenced by the quarkus.container-image.name #33554

Closed
cescoffier opened this issue May 23, 2023 · 9 comments · Fixed by #33724
Closed

Kubernetes name influenced by the quarkus.container-image.name #33554

cescoffier opened this issue May 23, 2023 · 9 comments · Fixed by #33724
Assignees
Milestone

Comments

@cescoffier
Copy link
Member

Describe the bug

I have an application. It sets the image name to quarkus.container-image.name=hide-and-seek-${quarkus.application.name}. I didn't expect this to change the name in my kubernetes descriptor:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    app.quarkus.io/build-timestamp: 2023-05-23 - 11:46:15 +0000
    app.quarkus.io/commit-id: 8ebd4faa57246c018ed32642bdc6be234b0e8bfc
  labels:
    app.kubernetes.io/version: 1.0.0-SNAPSHOT
    app.kubernetes.io/name: hide-and-seek-place-service
    app.kubernetes.io/managed-by: quarkus
  name: hide-and-seek-place-service
---

According to @iocanel it's not intended and it's a bug

Expected behavior

Setting quarkus.container-image.name should not change the kubernetes names.

Actual behavior

Setting quarkus.container-image.name is used in my kubernetes descriptor (for the names)

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

@cescoffier cescoffier added the kind/bug Something isn't working label May 23, 2023
@quarkus-bot
Copy link

quarkus-bot bot commented May 23, 2023

/cc @Sgitario (kubernetes), @geoand (kubernetes), @iocanel (kubernetes)

@cescoffier
Copy link
Member Author

I just added the service account, but it's the case for all the names used in my generated descriptor.

@iocanel
Copy link
Contributor

iocanel commented May 23, 2023

It seems as if intended, though out of context it doesn't really make much sense:

Need to get back and see why this was added.

@iocanel
Copy link
Contributor

iocanel commented May 23, 2023

The change was introduced in #7396 in an effort to reduce the need of copying group, image, version among (container image, kubernetes, openshift & knative config).

While the idea is not bad, it certaintly can get confusing. It took more than a quick glance to realize it was intended. So 🤷

@cescoffier
Copy link
Member Author

Hum... still confusing.
I will set the name. For the version, it's also confusing, as the version schema of images is likely different from the maven one.

@iocanel
Copy link
Contributor

iocanel commented May 24, 2023

Agree, it sounded like a good idea at the time, but it is confusing. @geoand @Sgitario your thoughts?

@Sgitario
Copy link
Contributor

Agree, it sounded like a good idea at the time, but it is confusing. @geoand @Sgitario your thoughts?

I agree with @cescoffier : one thing is the container name and another thing the application name. The application name does make sense to be equal to the name of the generated resources.

@geoand
Copy link
Contributor

geoand commented May 24, 2023

Yeah, I guess we should change it

@cescoffier
Copy link
Member Author

Awesome! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
4 participants