[devworkspace] How to handle configuration spread across DWO, WTO and DWCO

[metlos]

Abbreviations used:

WTO - web terminal operator
DWCO - devworkspace che operator (considered merged with che operator)
DWO - devworkspace operator

This is recap of possible solutions to our problem of configuring multiple operators using a single(-ish) source of truth. I personally prefer the 3rd variant - contextual config of DWO - but we should discuss all the alternatives and pick the one that suited best to our whole "ecosystem".

Handling configuration across components

Constraints

• ideally, single "devworkspace environment" in the cluster (e.g. no support for multiple "che clusters")
• devworkspace operator needs to also handle webterminal
• configure only "user facing" operators (WTO, DWCO) and cascading the config to the lower level operator(s), if possible
• We don't know the order in which the user installs WTO and DWCO

Possible solutions

Configuration spread across configuration of individual operators

Pros:

• conceptually simple
• separation of concerns

Cons:

• because there is a single config of DWO, WTO and DWCO have to share the same configuration for those "lower level details"
• configuration spread across several places
• reduced UX because the user needs to remember/learn where pieces of configuration are placed

Lower level operator (DWO) configured through the higher level operator that installed it (WTO or DWCO)

Configuration of WTO and DWCO are superets of configuration of DWO. The operator that installs DWO has enough permissions
to configure DWO. The other operator cannot configure DWO and needs to somehow communicate that to the user.

Pros:

• only top level operators are configured by the user

Cons:

• might be confusing for the user, because the place of configuration depends on the order of installation of the top level operators

Contextual lower level configuration based on the source of config (WTO, DWCO)

Configuration of WTO and DWCO are supersets of configuration of DWO. There exists multiple copies of configuration for DWO
each containing specifics for the respective top level operator. This would be handled by a new CRD and the CRs would be owned the respective top-level operator deployments.

At workspace reconciliation time, DWO would pick the configuration to use based on routingClass of the Devworkspace being deployed (or maybe label or some other attribute that we need to add to the schema).

Top level operators would contain all the configuration and would cascade the DWO portions to the contextual CR they own.

Pros:

• Each top-level operator can have a truly standalone configuration
• conceptually simple
• Allows for independent workspace hosts per top-level operator (e.g. wto.cluster.com/ws1 and dwco.cluster.com/ws2)

Cons:

• Most work
• DWO configuration needs to exist for each top level, possibly needlessly copied

[nickboldt]

Seems like something we should figure out sooner rather than later, so setting P1. Will this be in the next sprint?

[sleshchenko]

I personally prefer the 3rd variant - contextual config of DWO

I think it can be considered as #1 from #19189 (comment)

[nickboldt]

Related issue: https://issues.redhat.com/browse/CRW-1730

[l0rd]

After this week dw cabal discussion we decided to close this issue as it's not relevant anymore.