Support TLS edge termination to expose http endpoints.

[eye0fra]

Describe the bug

When setting up an endpoint for a HTTP service with specific attributes, the correct edge route URL is generated without the urlRewriteSupported: 'true' attribute.

However, accessing this endpoint through the VSCode UI Endpoint section results in a 404 error.

Additionally, attempting to use the urlRewriteSupported: 'true' attribute prevents the route from being created, I assume as expected.

Che version

7.89@latest

Steps to reproduce

When setting up the following endpoint:

    - exposure: public
      targetPort: 5050
      name: web
      protocol: http
      secure: true
      attributes:
        discoverable: true

the correct route URL is generated without the urlRewriteSupported: 'true' attribute. However, accessing the endpoint through the UI Endpoint section results in a 404 error.

when using urlRewriteSupported: 'true' attribute the route is not created.

Steps to Reproduce:

1. Deploy a devfile with the following endpoint configuration:

   - exposure: public
     targetPort: 5050
     name: web
     protocol: http
     secure: true
     attributes:
       discoverable: true

2. Access the service endpoint via the VSCode UI Endpoint section:
   https://<devspace-url>/<devspace-userid>/<devfile-name>/5050/

Expected Result:

The service should be accessible via the UI Endpoint without any errors.

Actual Result:

Accessing the endpoint through the UI Endpoint section results in a 404 error.

Notes:

• Without the urlRewriteSupported the Route URL is correctly generated and you can access from the OpenShift Console.

Expected behavior

The service should be accessible via the UI Endpoint without any errors.

Runtime

OpenShift

Screenshots

Installation method

OperatorHub

Environment

other (please specify in additional context)

Eclipse Che Logs

No response

Additional context

On-premise installation

[AObuchow]

I was able to reproduce this issue with the following devfile:

schemaVersion: 2.2.2
metadata:
  name: python
  displayName: Python
  provider: Red Hat
  version: 3.1.0
projects:
  - name: flask-example
    git:
      remotes:
        origin: https://github.com/devfile-samples/python-ex
components:
  - name: py
    container:
      image: registry.access.redhat.com/ubi9/python-39:1-192
      args: ['tail', '-f', '/dev/null']
      mountSources: true
      endpoints:
        - name: https-python
          targetPort: 8080
          protocol: http
          secure: true
          attributes:
            discoverable: true
        - exposure: none
          name: debug
          targetPort: 5858
      env:
        - name: DEBUG_PORT
          value: '5858'
commands:
  - id: pip-install-requirements
    exec:
      commandLine: pip install -r requirements.txt
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: build
        isDefault: true
      component: py
  - id: run-app
    exec:
      commandLine: 'python app.py'
      workingDir: ${PROJECT_SOURCE}
      component: py
      group:
        kind: run
        isDefault: true
  - id: debug-py
    exec:
      commandLine: 'pip install debugpy && python -m debugpy --listen 0.0.0.0:${DEBUG_PORT} app.py'
      workingDir: ${PROJECT_SOURCE}
      component: py
      group:
        kind: debug

To encounter the bug, run the devfile commands pip-install-requirements then run-app from the CheCode UI. When the endpoint notification pops up, click "Open in New Tab"

You'll be redirected to a page with 404 page not found.

If you get the devworkspace id <devworkspace-id>, and find the route named <devworkspace-id>-py-8080-https-python, you can verify that the route location works and gives a Hello World!:

I suspect this is a Che-Router issue but it might be a DevWorkspaceRouting issue.
Further investigation needs to be done on the DWR and Che-Router side.

@tolusha let me know if you have any immediate thoughts that come to mind.

[AObuchow]

So far, I believe this is a Che Router bug, because this bug does not occur when using DevWorkspace Operator's "basic" routing class. To verify this, I created the following devworkspace on the dogfooding instance of Che. After creating the workspace, you can easily visit the URL from the list of workspace in the Dashboard:

kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: code-latest-tls-bug
spec:
  started: true
  routingClass: 'basic'
  template:
    projects:
      - name: flask-example
        git:
          remotes:
            origin: https://github.com/devfile-samples/python-ex
    components:
      - name: dev
        container:
          image: quay.io/devfile/universal-developer-image:latest
          memoryLimit: 512Mi
          memoryRequest: 256Mi
          cpuRequest: 1000m
          endpoints:
            - name: https-python
              targetPort: 8080
              protocol: http
              secure: true
              attributes:
                discoverable: true
    commands:
      - id: pip-install-requirements
        exec:
          commandLine: pip install -r requirements.txt
          workingDir: ${PROJECT_SOURCE}
          group:
            kind: build
            isDefault: true
          component: dev
      - id: run-app
        exec:
          commandLine: 'python app.py'
          workingDir: ${PROJECT_SOURCE}
          component: dev
          group:
            kind: run
            isDefault: true
  contributions:
    - name: che-code
      uri: https://eclipse-che.github.io/che-plugin-registry/main/v3/plugins/che-incubator/che-code/latest/devfile.yaml
      components:
        - name: che-code-runtime-description
          container:
            env:
              - name: CODE_HOST
                value: 0.0.0.0

Once the workspace starts up, run the devfile commands pip-install-requirements then run-app from the CheCode UI.

Once you get the port notification in the bottom right of the editor, open it, and you'll see the web server is accessible from the URL:

[AObuchow]

I think I've finally found the source for the bug.
The Che Router will associate all routes/ingresses with the workspace's common service rather than checking if a service exists for that specific route/ingress. An endpoint-specific service is created when the discoverable attribute is set on an endpoint, and this service should be associated with the endpoint's route/ingress.

I made a draft patch and tested this, and am able to confirm that the issue no longer occurs with my reproducer.

I'll be working on a PR to fix this.