Support one namespace per user strategy (che.osio like)

[l0rd]

Currently a Che admin has 2 options to specify in what namespace the workspaces pods will be started:

• Use one namespace for all the workspace of every Che user (security issue)
• Create a new namespace for every new workspaces (resources issue)

An approach that looks like more suitable for most real-world use cases is to deploy all workspaces pods of a given user in one of the user namespaces. That's the approach that has been implemented for che.openshift.io.

That has the merit to make it closer to have an upstream che / che osio parity (c.f. #13265)

[l0rd]

cc @skabashnyuk @ibuziuk @sleshchenko

[skabashnyuk]

I would like to clarify the technical scope of this task.
Could it be like:

Case osio.like - CHE_LIMITS_USER_WORKSPACES_RUN_COUNT=1

• We need to update documentation explaining how to do that and what is the benefits from that.
• allow to use ${username}, ${userid} patterns in configuration
  parameters that are defining target namespace.
  https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L380
  https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L586
• add a note to the documentation that compatible PVC strategies are: unique, common and perWorkspace

Case CHE_LIMITS_USER_WORKSPACES_RUN_COUNT>1

• Make sure we are capable to create multiple workspaces from the same devfile that comes from the registry.
  We can't do that from these devfiles https://github.com/eclipse/che-devfile-registry/search?q=discoverable&unscoped_q=discoverable
  because of the service name conflicts.
• Check and improve message explaining possible name conflicts and the variants on how to solve/avoid/workaround it.
• add a note to the documentation that compatible PVC strategies are: unique and perWorkspace

[l0rd]

Case osio.like - CHE_LIMITS_USER_WORKSPACES_RUN_COUNT=1

If I had to choose it I would say that this should become the default. As an k8s cluster admin I would be happy because it would save resources. As a developer I would not care about having 2 workspaces running at the same time. And for us it means less issues open. But that's something that should be validated by @slemeur.

• We need to update documentation explaining how to do that and what is the benefits from that.

Ok

• allow to use ${username}, ${userid} patterns in configuration
  parameters that are defining target namespace.
  https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L380
  https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L586

Ok

• add a note to the documentation that compatible PVC strategies are: unique, common and perWorkspace

Ok

Case CHE_LIMITS_USER_WORKSPACES_RUN_COUNT>1

The problem of the overlapping services is not something new. We currently have it when we set che.infra.kubernetes.namespace (default for single user configuration). That's not something that would be introduced with this new namespace strategy and I would not consider it in the scope of this issue. It's part of #14382.

[kameshsampath]

it would also be nice to have CHE_LIMITS_USER_WORKSPACES_RUN_COUNTand namespace configurable via CheCluster CRD as then that can be used che to provision the workspace based on the need.

[skabashnyuk]

@kameshsampath will create a separate issue about that.
@slemeur any comments about that #13488 (comment) ?

[sparkoo]

we cannot use ${} as a placeholder. These are evaluated at server start-time so having ${username} at that point does not make sense. We need another placeholder that will be evaluated at runtime (workspace start-time).

[skabashnyuk]

what about <username>?

[sparkoo]

In current PR, I went with <username> placeholder.
Regarding the documentation: namespace strategies are not documented yet at all (https://github.com/eclipse/che-docs/blob/master/src/main/pages/che-7/installation-guide/proc_configuring-namespace-strategies.adoc). Whole installation guide is basically empty and not even reachable from menu (https://github.com/eclipse/che-docs/tree/master/src/main/pages/che-7/installation-guide). I don't think it's a good idea to start documenting it from the middle, before any structured document is created.

[sparkoo]

fixed by #14524

[alexeykazakov]

Can you please elaborate on this new feature.

How we could use it in Hosted Toolchain (Will replace OpenShift.io) to create workspaces in some specific namespace? Let's say in {username}-code namespace.

Also, in the PR you mentioned that feature requires cluster-admin which is problematic in OSD. What exactly is required in terms of permissions for that feature?

[sparkoo]

@alexeykazakov for your example set CHE_INFRA_OPENSHIFT_PROJECT to <username>-code. If you use OpenShift oauth, it should work. If not, your serviceaccount will have to have permissions to create new namespace.

[alexeykazakov]

Will it work if {username}-code already exists?

[sparkoo]

yes, it should just use it.

[gorkem]

@sparkoo Do you have updates to the docs related to this feature ?

[skabashnyuk]

@gorkem we did not find an appropriate place for them yet. We are going to handle that next week.

[sparkoo]

@gorkem there is page prepared https://github.com/eclipse/che-docs/blob/master/src/main/pages/che-7/installation-guide/proc_configuring-namespace-strategies.adoc but no content there yet. If you have doc where we can document this feature, I'm happy to update that.

[gorkem]

@rkratky The above location looks right to me but is there anything I am missing?