Che: Revise Organization/Resources functionality

[skabashnyuk]

Is your task related to a problem? Please describe.

Organization and Resource API originally was targetting on Docker infrastructure.
In Che 7 era that is targetting K8S based infrastructures, such capabilities can't be fully implementing. For example, that's not possible to
create a workspace in (some) organization namespace and simply just add and remove users.

Describe the solution you'd like

The goal of this pr is to revise what we had in Che 6 and the possibility to implement it with Che7 on K8S API.

At this moment I can suggest.

• Remove such thing as "Organizations" at all.
• With "sharing" - allow only to access other users to the owner's workspace. No ability to change workspace owner.

Describe alternatives you've considered

n/a

Additional context

n/a

[skabashnyuk]

CC @l0rd @davidfestal @slemeur

[l0rd]

I am +1 to remove orgs at all
I am -1 for allowing workspace sharing capabilities since this means giving access to sensitive data as SSH keys or kubernetes/openshift tokens.
Sharing should be through devfile/factory link only

[gazarenkov]

Organization API gives a way to make Che a manageable development platform for enterprise and hosted offer.
Ability to share workspace runtime gives a way of collaborate remotely (yes, it gives access to all the data, but it is not intended to share runtime to everyone, it's like allowing remote college access to your local machine for debugging).
I'd say both features bring value and make up Che as a holistic, manageable, collaborative platform.
IMO it is a big differentiator and I would not like to throw those away w/o proper analysis.
CC: @bmicklea @slemeur

[slemeur]

No.
There is no intention to remove the organizations, which are still features that are important and beneficial in a cloud IDE. Teams and collaboration aspects are big part of the value of Che, removing those would be decreasing the value of the product. @gazarenkov is perfectly right!

Instead of thinking about removing it, we need to analyze properly the capabilities that are working and the ones that are not working anymore and adapt.
Based on the analyze, we can adjust the functionalities and guide the user (or admin in this case) to either use the underlying platform to operate the some actions or understand the limited scope of the actions from the dashboard.

[bmicklea]

Has there been any other analysis of this problem?

[l0rd]

@bmicklea not that I am aware of. Here are my thoughts:

• Organisations, as a way to select the stacks, plugins, and resources available to groups of users, still make a lot of sense.
• Workspace instances sharing, with its lack of isolation (same pod, same secrets), and its poor usability (two users, one cursor) need to be rethought and should be disabled right now.
• Devfiles are a way to share workspaces definitions and we should rethink workspace sharing use cases based on it.

[bmicklea]

+1 to all of those, but I do think that we need a multi-cursor support for Che. Something "Google Docs-ish" is often asked for.

[mingfang]

I want to use Organizations to managed billable resources. If selling Che as a SaaS, customers would pay for a Root Organization with a set number of workspaces, CPU/Memory/Storage, users, and maybe sub-organizations. Also the customer needs be able to grant user permissions to those resources, e.g. Team A gets X resources and Team B get Y resources.

[sleshchenko]

I want to use Organizations to managed billable resources. If selling Che as a SaaS, customers would pay for a Root Organization with a set number of workspaces, CPU/Memory/Storage, users, and maybe sub-organizations. Also the customer needs be able to grant user permissions to those resources, e.g. Team A gets X resources and Team B get Y resources.

It's exactly the case we covered with Organizations on Docker infrastructure.
But K8s/OS infra has its own RBAC and Resources Model (aka Quotas) and currently, Che Organization API does not take them into account which may lead to unexpected behavior.

[davidwindell]

Please don't abandon sharing, not a day goes by when one of our developers doesn't share a workspace with another developer (we are a web agency). Sometimes it is just faster and easier to jump into another dev's already running workspace and quickly fix a problem for them.