All endpoints (ingress) have the same secretName

[batleforc]

Describe the bug

Will working on a web project (Api Rust, Front JSxRust), i set up 3 endpoints that end up with 3 different DNS and should likewise have 3 different secretname

Che version

7.84@latest

Steps to reproduce

1. Create a workspace that have 3 endpoint setup (private)
2. Wait for it to be up
3. use the following command that will output the name of all the secret
   kubectl get ingress | grep "{Workspace Name}" | awk '{print "kubectl get ingress " $1 " -o yaml | yq .spec.tls[0].secretName"}' | bash

The endpoints is like the pod's name ending with "-endpoints"

Expected behavior

Each endpoint should have a different SecretName like {pod name}-{endpoint name}-endpoints wich would allow each endpoint to have a valid certificate generated with CertManager

Runtime

Kubernetes (vanilla)

Screenshots

No response

Installation method

chectl/latest, chectl/next

Environment

Linux

Eclipse Che Logs

No response

Additional context

No response

[RomanNikitenko]

@AObuchow
could you take a look

[batleforc]

Any news ?

[AObuchow]

@batleforc do you happen to have a reproducer devfile for this? Is there some specific configuration required for the endpoints? I apologize for taking so long to look into this issue.

[batleforc]

Hello @AObuchow ,
Every devfile with at least one https endpoint:

- name: https-3000
  targetPort: 3000
  exposure: public
  secure: true
  protocol: https

Once the workspace created, you can check the main ingress and the one bind to https-3000 and see that they have the same secretName.
(I have a similar problem for Openshift, but more in the annotations aren't applied to the sub routes)

[AObuchow]

(I have a similar problem for Openshift, but more in the annotations aren't applied to the sub routes)

@batleforc Could you please clarify the issue that occurs on OpenShift in more detail? This seems to be a separate issue if I'm not misunderstanding? Please try to provide an example of an endpoint that causes your issue as well as the expected vs actual behaviour. It might make sense to open up a new Che issue for this (which I can gladly do for you once I understand the issue). Thank you :)

[batleforc]

The issue with OpenShift is that we need to have some annotations put on the route in order to have HTTPS, but in the current case no annotation goes down to the end user route.
I think too that it needs another issue has this isn't a problem of secret being the same.
I won't be able to create it yet has I'm on my phone but i will do it as soon as possible.

[AObuchow]

The issue with OpenShift is that we need to have some annotations put on the route in order to have HTTPS, but in the current case no annotation goes down to the end user route. I think too that it needs another issue has this isn't a problem of secret being the same. I won't be able to create it yet has I'm on my phone but i will do it as soon as possible.

Sounds good, thank you for the quick reply @batleforc :)

Have you seen that we added support for endpoint annotations from the devfile specification? See "Support devfile endpoint annotations" in the Che 7.92 release notes. Here's the associated PR.

I wonder if this is the feature you were looking for?

[batleforc]

The issue with OpenShift is that we need to have some annotations put on the route in order to have HTTPS, but in the current case no annotation goes down to the end user route. I think too that it needs another issue has this isn't a problem of secret being the same. I won't be able to create it yet has I'm on my phone but i will do it as soon as possible.

Sounds good, thank you for the quick reply @batleforc :)

Have you seen that we added support for endpoint annotations from the devfile specification? See "Support devfile endpoint annotations" in the Che 7.92 release notes. Here's the associated PR.

I wonder if this is the feature you were looking for?

Yes I've seen it, it's more or less what I intended, in our case we need those annotations to be by default and not opt-in

[AObuchow]

Yes I've seen it, it's more or less what I intended, in our case we need those annotations to be by default and not opt-in

I think your issue would be #23118 then 😎 If that's the case, please leave a comment on it just asking for the issue to be prioritized. Otherwise, please submit a new issue and tag "@" me in it :)

[Deddinho23]

Absolutely up!

It would be really nice to have the possibility of having multiple endpoints with their own certificate issued by Cert Manager thanks to the annotation.

At the moment we are using a workaround that consists in removing the owner reference from metadata in the certificate resource and adding all the endpoints URL of the workspace under the spec.DNSnames, but it's quite annoying doing all this manual job whenever a new workspace coming out...