Discover an ability to configure Dashboard easier

[sleshchenko]

Is your task related to a problem? Please describe.

Currently, the Dashboard is customizable with product.json file which capabilities will be extended soon.
But the current approach of overriding product.json is not so easy, it still requires repackaging Dashboard and then new Che with it.
For example, Code Ready Workspace assembly https://github.com/redhat-developer/codeready-workspaces/tree/master/assembly/codeready-workspaces-assembly-dashboard-war/src/main/webapp/assets/branding.
Another case of configured Dashboard is che.openshift.io which does not change the branding but tune some default behavior (disable organization tab, disables workspace sharing, an ephemeral mode is enabled by default) https://github.com/redhat-developer/rh-che/tree/master/assembly/fabric8-ide-dashboard-war

This issue is about discovering an ability to configure Dashboard easier.
I can imagine that Dashboard could continue to have product.json but it would be a default configuration that administrators would be able to patch on Deployment level with ConfigMap, Volumes, etc.

 title: My Branded Che
 menus.organization.enabled: false
 footer.faq: ""

But it's needed to be analyzed more and discussed with wider the audience.

[sleshchenko]

cc @nickboldt @l0rd @slemeur @ibuziuk

[benoitf]

I still think it needs to be served through branding service
I mean, dashboard is running on client side so it needs to have configuration served by the server to be used with configuration (config, map, etc)
#14839 (comment)

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[sleshchenko]

/remove-lifecycle stale

[sleshchenko]

A bit more detailed description of the idea:
Involved members - Admin, BrandingService, Dashboard (does not matter which one, the current or next), chectl may be interested in consuming such configuration as well.

Branding Service is a REST API Service that is responsible for distributing branding settings like product name, icon link, docs links, CDN. We also need to customize client's behavior, like hide some functionality like menus.organization.enabled, kubernetesNamespaceSelector not sure if it's branding or not. Maybe that service should be more general and there should be different levels/domains of settings, like branding, clients, … Or such settings should be moved to the corresponding API, like workspace API has a configuration to tell which storage types are available.

Currently, the dashboard has embedded defaults that are used when it's failed to load product.json or when product.json misses requested parameters (like OSIO since it does not need to override everything). The proposal is to change it and make a branding service requirement for successful dashboard initialization. If it's unavailable - Dashboard should show general information about server misconfiguration/unavailability. It would prevent showing defaults (Che product name) in rebranded downstream ( like CRW ).

A bit more about branding and how it can be configured by Admins on the installed cluster without rebuilding:
Currently, we have a solution when Dashboard behavior can be customized via Che Server settings - https://github.com/eclipse/che/blob/master/wsmaster/che-core-api-workspace/src/main/java/org/eclipse/che/api/workspace/server/WorkspaceService.java#L421
The corresponding properties (which are consumed by Dashboard ) are propagated by Che Server are configured via che.properties, or if we talk about installation - through CheCluster.spec.server.customCheProperties.
So the simplest solution could be just introducing a new REST API server on the Che Server-side and then introduce new configuration parameters, like che.product.name, che.product.logo_url, che.product.docs.overview, ...
The preferable way to customize it - as described above - through Che Server via CustomResource, some new field could be introduced specific to our needs, like CheCluster.spec.server.branding or whatever the best name is.

If it makes any sense - we could also think about providing an ability to configure custom branding server endpoint(dedicated from Che installation). But then a custom branding server must follow the new API we introduce (new documentation links) and it can be error-prone. With embedded service - the defaults could be just used.

We should think about safe solutions for downstream which need to override almost everything and they want to know when new properties are added. So, some validation may be enabled at some point.

The alternative which can be considered as well: branding service as a standalone application(not part of Che Server)... It definitely has some cons but it would complicate things... So, personally I vote for Che Server embedded branding service.

@benoitf I believe it's what you referenced, any comments?
@skabashnyuk @l0rd WDYT?

Update:
TODOs:

1. Except configuring icon URL it also may it convenient to put somewhere image that will be served by the server otherwise admin should host icon somewhere else which I think should not be an issue but not very convenient. But putting image or any other binary in CR like with base64 help does not seem nice.
2. If we take into account devworkspace controller use-case, is there a need to have a branding service run without Che operator installed (Che Server available). Like to chectl or che-theia supply it. If we need - we should consider implementing a separate service for that.
3. We did not take into account css files which may be needed to customize as well in white-labeling purposes. It should be pretty easy doable in the same way if custom css is available through HTTP but if Che Server needs to serve it - API should be adapted... And having the whole css file in the CR does not seem to be a good idea.

[nickboldt]

base64 image encoding is already in use in CSVs for Che and CRW; transforming the icon in Che to CRW as a whitelabel operator isn't too hard using yq to swap in a new image blob.

https://github.com/eclipse/che-operator/blob/master/olm/eclipse-che-preview-kubernetes/deploy/olm-catalog/eclipse-che-preview-kubernetes/7.18.2/eclipse-che-preview-kubernetes.v7.18.2.clusterserviceversion.yaml#L220-L222
then
https://github.com/redhat-developer/codeready-workspaces-operator/blob/crw-2.4-rhel-8/build/scripts/sync-che-olm-to-crw-olm.sh#L91-L113

Could do the same with the css file(s) and other text artifacts.

[l0rd]

As mentioned yesterday I would avoid extending the che server API but rather:

• STEP1 - running the HTTP server that serves the dashboard in its own pod: customising the dashboard is just a matter of rebuilding the dashboard container image.
• STEP2 - mounting the customizable resources (images, text etc...) using config maps: customising is a matter of updating the CM and restarting the dashboard pod
• STEP3 - updating the CheCluster CRD adding a dashboard-customisation section with attributes that reference the CM that contains the customisable resources loaded by the dashboard.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[sleshchenko]

it's moved to the enhancement #20666