Move dashboard out of che server container

[sleshchenko]

Is your task related to a problem? Please describe.

Currently, dashboard and dashboard-next are built into their own apache server containers, but then static resources are copied from those containers and are repacked into tomcat along with Che Server.

Describe the solution you'd like

This issue is created to collect thoughts/idea if it makes more sense to start serving dashboards from separate containers.

Pros

1. That solution may be more flexible in customization. You can use a custom-built dashboard without the need to rebuilt Che Server.
   2... ?

Cons

1. More memory is needed to start Che.
   2... ?

Open questions

1. Should Che Server and Dashboards be run in the same Deployment or separate ones?
   Probably separate - then we would have some UI even if Che Server is not available.

2. Should Che Server and Dashboard be served on the same host?
   Probably yes, otherwise authentication should be adapted if it's even possible.

[sleshchenko]

cc @l0rd @benoitf @skabashnyuk

[skabashnyuk]

The thing that might become complicated is the routing. We need some sort of reverse proxy to route traffic between different servers.

[sleshchenko]

The thing that might become complicated is the routing. We need some sort of reverse proxy to route traffic between different servers.

I believe route/ingress can handle it we just need to configure the right paths for them.

[sleshchenko]

The current state:

Prerequisites:

• to avoid CORS issues it's better to run Dashboard and Che Server on the same host;
• running multiple containers in the same deployment does not have any obvious pros, so run Che Server and Dashboard as separate deployments;

Stage 1
We have prototypes for helm chart and che-operator that runs dashboard as separate deployment. Note that not everything is tested and probably Traefik-based SingleHost is not working yet
https://github.com/sleshchenko/che-operator/tree/separateDashboard
https://github.com/eclipse/che/tree/separateDashboard
The only difference from the previous approach - Dashboard is served from different deployment via $CHE_HOST/dashboard endpoint. These changes can be merged after they are finalized and better tested as stage 1.

• Che Server still serves a number of javascript resources:
  • Workspace loader which is going to be deprecated as well with dashboard. So, it will continue to be served by Che Server until deprecation time. New Workspace Loading page will be integrated into Dashboard Next;
  • workspace authentication app (aka loader.html) + workspace oauth token provider: are going to be served via Che Server since they are not related to the dashboard;
  • swagger UI: is going to leave on Che Server since it's tight to Che REST API.

Stage 2
Dashboard Next is still served by Che Server. Since Dashboard Next is going to just replace Dashboard one day - the idea is to go a simpler way and serve them from the same container.
Since they are located in different repositories, the build/release workflow can be the following:

• Dashboard is built into Apache server as previously https://github.com/eclipse/che-dashboard/blob/master/apache.Dockerfile;
• Dashboard next instead of basing on bare apache will be based on Che Dashboard image and will provision its resources to be available via the corresponding path;
• Che deployment uses dashboard next image that contains both (dashboard and dashboard Next). It seems to be logical to implement it as part of Set up release for Dashboard Next #17647;
• CRW still uses Dashboard image until we declare Dashboard Next is ready to be used in CRW;

Stage 3
After previous stages, Che Server is still main endpoint that handles / to Che application and does a number of redirects, like / -> /dashboard, ^/f/$ -> /dashboard/#/load-factory/. When Che API (mainly REST API) is not available - user gets 503 error from OpenShift.
It makes sense to consider making Dashboard as the main endpoint, which correctly handles cases when Che API is not available and provides nice error message. Dashboard also handling its shotcuts/redirects like f?url to factory flow.
The idea is pretty simple but implementation has some difficulties and it's why it's moved to the latest stage:

• Che Server still serves: /api, /swagger, /app (which potentially can be renamed to /workspace-auth):
  • kubernetes allows to easily configure multiple paths to one service with ingresses, so we would have dashboard as / and Che Server with listed paths(/api, /swagger, /app);
  • OpenShift Routes does not allow to specify multiple paths, so we would need to go one from the following:
    • move everything from /api, /swagger, /app to have a common path segment, can't propose a good one;
    • create 1 route for the dashboard and 3 routes only for Che Server deployment, one per path;
    • have 1 route that will be pointed to reverse-proxy and it will proxy requests according to needed rules via cluster dns (based on k8s services) * AFAIU similar what we do for OpenShift Single Host support.
    • anything else;

[ibuziuk]

From Hosted Che perspective it would be much appreciated to have a property that would still allow serving UD from the Che server pod in order to continue using the deployment template we are having in the downstream - https://github.com/redhat-developer/rh-che/blob/master/openshift/rh-che.app.yaml
In the short run we are going to switch to the operator based deployment in the new version of SaaS, but until then this property will be enabled in rh-che to make it possible to use current template without customizations

[gorkem]

Is this going to allow to run multiple dashboard instances to support horizontal scaling?

[sleshchenko]

Is this going to allow to run multiple dashboard instances to support horizontal scaling?

Since dashboard is going to be served by apache server without any persistence - yes, we can easily enable as many dashboards server instances as we need )

[sleshchenko]

Update: it makes sense to move forward in that way in an iterative manner. So we'll implement it for helm chart #18076 (7.21.0) and then for che-operator(probably 7.22.0 but no a commitment at this point).

[sleshchenko]

That's finally done. The only thing that is left - adapting dashboard happy path tests which has a dedicated issue #19652

[themr0c]

Release notes: https://issues.redhat.com/browse/CRW-1865