Che Server resignation

[gazarenkov]

WHAT: Remove Che Server component

WHY: The main functionality of Che Sever is already moved to the DevWorkspace engine and it is not rational and risky (from supportability standpoint) to keep it more than needed. Indeed:

• there is quite a big codebase for support for (already) small functionality
• it is probably the only component which uses Java technology (supportability risk)
• it is not consistent with current architecture
• we have limited resource capacity for supporting it
  So, it is better to have a clear strategy about its resignation better sooner than later

HOW:

1. It seems we need to keep Workspace API to be able to transform workspaces to the new format. AI: to define till what version @ibuziuk
2. seems we still use in IDE some APIs such as User Profile, Preferences, SSH and Postgre DB based storage for it. AI: (if so) to consider other mechanism and EOL for those APIs and Postgre @azatsarynnyy (?)
3. Namespace provisioning. AI: consider other place for this component (at some point we've had it in UD but moved by some reason?) @ibuziuk
4. Workspace factory. @skabashnyuk

Implementation

• Che7 workspaces based API. Approximate eta 7.47
  • Workspace API
  • Che 6 Permissions API
  • Che 6 Organization API
  • Che 6 Organization resource API
  • Che 6 Resource API
  • Activity API
  • Che7 workspace metrics
• Deprecated or abandoned API Approximate eta 7.47
  • Persistent devfile 1.0
  • SSH API
  • Keycloak API/resources
  • Token API
• Secondary API Approximate eta 7.47
  • User API
  • Profile API
  • Preference API
• JPA persisnance layer. Approximate eta 7.47
• API in use.
  • Factory/SCM resolve (Replacement with SPI)
  • Devfile schema API (Move to the place where it used)
  • OAuth1/2 (Replacement with SPI)
  • Kubenernetes namespace (TBD)
  • Kubenernetes namespace provision (TBD)

[ibuziuk]

From the Developer Sandbox supportability perspective it would be really nice to remove user profile management from 'che-server'
component. This is how the usr entry looks like in the latest version after provisioning on the OpenShift cluster:

dbche=> select * from usr;
                  id                  |   email   |                                                                        password                                                                  
       | name  
--------------------------------------+-----------+--------------------------------------------------------------------------------------------------------------------------------------------------
-------+-------
 3bb98fb1-ef97-4df8-9c22-a2104aa3ecbd | user1@che | c08c77292a739b50fdb8b41b264484435c01c0eeb34975e663e3d609954781e95e4534e56206ced3bc492a53a7aa9fa9162c62428e5f4880d10b833da8a7ccb4:844885baec0599a9
:10000 | user1
(1 row) 

id - matches OpenShift user uid
name - matches OpenShift user name
email - dummy one and this is misleading (on the Dashboard user is shown with the incorrect email with @che postfix)
password - legacy code from Codenvy era (hash from the 'password'). Obsolete since Che become Multiuser

dashboard still uses this info on the account page which results in the irrelevant account info:

The motivation for removing user management from the che-server / db is the fact that users are deprovioned every 30 days according to the TOS, and during the de-provioning toolchain needs to explicitly cleanup the users entries from the che-server / db. In the curent version of Eclipse Che we need to let OpenShift handle the user management instead.

[nickboldt]

Note downstream issue https://issues.redhat.com/browse/CRW-2901 re: account editor being readonly

[azatsarynnyy]

None of the Che-Server APIs are used by Che-Theia when it's running in a DevWorkspace mode.
I've removed #21142 from the Implementation section. That issue is just about cleaning up the unused code.

[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.