1. Proposed title of this feature request
"Add Ability to access workspace external endpoints as paths to main workspace route"

2. What is the nature and description of the request?
Currently, When user creates an extranl endpoint in devfile.yaml, a new route is created, with the url of the form:

<user-id>-<workspace>-<endpoint-name>.<openshift cluster route base domain>

Admin should have the ability to globally configure dev spaces so the urls of external endpoints are not generated dynamically as new hostnames, but as paths to hostname of the main devspaces route. ex instead of above, the external endpoint url would be:

<devspaces-hostname>/<user-id>/<workspace>/<endpoint-name>

Currently this can be accomplished by adding urlRewriteSupported=true attribute to endpoint in devfile. But this is not desired solution due to the following:

• Developers must remember to add this to make sure external endpoints would work the way we want.

• The endpoint will be authenticated and only accessible to workspace owner. Customer would like to have the same behavior today, where any user can access the endpoint, unless it is explicitly specified somehow that the endpoint must be authenticated. ( They believe this is possible by adding secure: true endpoint definition)

3. Why does the customer need this? (List the business requirements here)
Customer need this because they're configuring a custom short url of dev spaces (devspaces.mycompany.io). that's not the same as default base domain of openshift cluster. to allow accessing workspace endpoints via the short url, they needed to setup a wild card tls cert and also wild card DNS record.

They are requesting this enhancement so it is enough to only configure TLS cert and DNS record of specific hostname (devspaces.mycompany.io) vs (*.devspaces.mycompany.io)

4. How would the customer like to achieve this? (List the functional requirements here)

We can specify a strategy attribute in checluster's networking attribute. something like externalEndpointsGenerationStrategy that has hostname or path as the value. This is just a suggestion but it can be anyway the team see fits that accomplish our goal above.

5. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

• Follow steps to configure generating external points as paths (using the recommended approach from this enhancement).
• Create a new workspace with the following devfile.yaml:

schemaVersion: 2.2.0
metadata:
  name: flights-mgmt
components:
  - container:
      image: udi:latest
      sourceMapping: /projects
        - name: test-endpoint
          targetPort: 3000
          exposure: public
          protocol: https
          secure: false # disable endpoint from being authenticated
    name: tools

• Verify the external endpoint can be accessed using <devspaces-hostname>/<user-id>/<workspace>/<endpoint-name>