Support Singlehost deployment in Devworkspaces #18583
Labels
engine/devworkspace
Issues related to Che configured to use the devworkspace controller as workspace engine.
kind/enhancement
A feature request - must adhere to the feature request template.
kind/epic
A long-lived, PM-driven feature request. Must include a checklist of items that must be completed.
severity/P1
Has a major impact to usage or development of the system.
Is your task related to a problem? Please describe.
Currently, devworkspace operator always uses ingresses to expose workspace endpoints (similar to the multi-host mode in Che).
It would be great to make it also support an analog of the singlehost mode of Che.
Describe the solution you'd like
It would be great if we could implement this as a separate controller out of the main devworkspace-operator. This would enable us to keep the main operator focused on the workspace lifecycle management and the concerns like workspace exposure would be delegated to other, potentially external, controllers.
The devworkspace operator already has a concept of
WorkspaceRouting
expressed as a standalone CR that is used to handle the different ways a workspace is exposed and already handles a couple such exposure types (openshift-oauth, web-terminal, basic, ...). We could take advantage of this concept and implement singlehost as a new type of workspace routing.Describe alternatives you've considered
We could implement this inside devworkspace operator itself as a new workspace routing solver. This would require deploying other components (if we copy the singlehost approach taken by Che, that would mean deploying Traefik from within the operator).
Additional context
This depends on devfile/devworkspace-operator#219
Subtasks:
The text was updated successfully, but these errors were encountered: