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

Add ability to override base domain of workspaces endpoints to match custom Che server hostname base domain #23249

Closed
achdmbp opened this issue Nov 13, 2024 · 6 comments
Assignees
Labels
area/che-operator Issues and PRs related to Eclipse Che Kubernetes Operator area/doc Issues related to documentation severity/P2 Has a minor but important impact to the usage or development of the system.

Comments

@achdmbp
Copy link

achdmbp commented Nov 13, 2024

Is your enhancement related to a problem? Please describe

When configuring custom hostname for Che as described Configuring Eclipse Che server hostname. Let's say we use che.devs.mycompany.com as the hostname, the behavior will be:

  • accessing che dashboard and IDE will use che.devs.mycompany.com
  • however, when devs defined public endpoints in their devworkspace, the generated routes will use the default base domain. the route will be for example: https://<user>-<workspace>-<endpoint-name>.apps.<default base domain>

Describe the solution you'd like

to support switching to a new cluster and keep same custom domain of che server, add ability to use same base domain of custom hostname to be used also to generate workspace endpoints

Describe alternatives you've considered

No response

Additional context

No response

@achdmbp achdmbp added the kind/enhancement A feature request - must adhere to the feature request template. label Nov 13, 2024
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Nov 13, 2024
@tolusha
Copy link
Contributor

tolusha commented Nov 13, 2024

@achdmbp
Try this by updating CheCluster CR:

spec:
  components:
    cheServer:
      extraProperties:
        CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<...>"

@dmytro-ndp dmytro-ndp added severity/P2 Has a minor but important impact to the usage or development of the system. area/che-server area/ux Issues related to User Experience Design area/che-operator Issues and PRs related to Eclipse Che Kubernetes Operator and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. area/che-server labels Nov 13, 2024
@achdmbp
Copy link
Author

achdmbp commented Nov 14, 2024

@tolusha thank you very much. this worked! I'm surprised this wasn't documented in the admin guide or maybe I missed it somewhere ?

also is there a way to change the strategy to serve the endpoints via the main che gateway. for example,

https://<che _url>/<user>-<workspace>-<endpoint-name>

instead of creating the endpoint as new routes. Using https://<che _url>/<user>-<workspace>-<endpoint-name> is much easier to point explicit DNS entry to openshift ingress router NLB. vs having to use wild card domain record to cover all endpoints

@tolusha tolusha added area/doc Issues related to documentation and removed area/ux Issues related to User Experience Design kind/enhancement A feature request - must adhere to the feature request template. labels Nov 15, 2024
@tolusha
Copy link
Contributor

tolusha commented Nov 15, 2024

@achdmbp
Unfortunately we didn't have that in the doc. We will add.

also is there a way to change the strategy to serve the endpoints via the main che gateway. for example,

cc @dkwon17

@cgruver
Copy link

cgruver commented Nov 19, 2024

@tolusha thank you very much. this worked! I'm surprised this wasn't documented in the admin guide or maybe I missed it somewhere ?

also is there a way to change the strategy to serve the endpoints via the main che gateway. for example,

https://<che _url>/<user>-<workspace>-<endpoint-name>

instead of creating the endpoint as new routes. Using https://<che _url>/<user>-<workspace>-<endpoint-name> is much easier to point explicit DNS entry to openshift ingress router NLB. vs having to use wild card domain record to cover all endpoints

Putting this here for visibility since I don't think it is documented:

Adding the attribute: urlRewriteSupported: true will achieve the desired result.

Note: The endpoints will now require authentication, so they will not be easily shared with others on your dev team if you are collaborating between developer of two services, or frontend & backend.

    endpoints:
    - name: node
      targetPort: 4200
      exposure: public
      protocol: https
      attributes:
        urlRewriteSupported: true
    - name: https-quarkus
      targetPort: 8080
      exposure: public
      protocol: https
      attributes:
        urlRewriteSupported: true

@achdmbp
Copy link
Author

achdmbp commented Nov 19, 2024

it will be great to have a global config to control the route generation strategy vs having it configured at the endpoint level.

It would also be great to control whether we need the generated endpoints to be authenticated or not

@tolusha tolusha moved this to 📅 Planned in Eclipse Che Team A Backlog Nov 20, 2024
@tolusha tolusha self-assigned this Nov 20, 2024
@tolusha tolusha moved this from 📅 Planned to 🚧 In Progress in Eclipse Che Team A Backlog Nov 21, 2024
@tolusha
Copy link
Contributor

tolusha commented Nov 22, 2024

The documenation added eclipse-che/che-docs#2826

@tolusha tolusha closed this as completed Nov 22, 2024
@tolusha tolusha moved this from 🚧 In Progress to ✅ Done in Eclipse Che Team A Backlog Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/che-operator Issues and PRs related to Eclipse Che Kubernetes Operator area/doc Issues related to documentation severity/P2 Has a minor but important impact to the usage or development of the system.
Projects
Status: ✅ Done
Development

No branches or pull requests

5 participants