Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default namespace strategy should be 1 namespace per user #18381

Closed
sunix opened this issue Nov 16, 2020 · 8 comments
Closed

Default namespace strategy should be 1 namespace per user #18381

sunix opened this issue Nov 16, 2020 · 8 comments
Labels
area/che-server kind/bug Outline of a bug - must adhere to the bug report template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P2 Has a minor but important impact to the usage or development of the system.

Comments

@sunix
Copy link
Contributor

sunix commented Nov 16, 2020

Describe the bug

Following the documentation, https://www.eclipse.org/che/docs/che-7/installation-guide/installing-che-on-google-cloud-platform/
The default namespace strategy was 1 namespace for all che:

Selection_046

This installation was done with chectl nightly-build 2 months ago (September 2020).

Expected behavior

Have a namespace per user strategy by default, something like:

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<username>
@sunix sunix added the kind/bug Outline of a bug - must adhere to the bug report template. label Nov 16, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Nov 16, 2020
@ericwill ericwill added severity/P2 Has a minor but important impact to the usage or development of the system. area/platform and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Nov 16, 2020
@sparkoo
Copy link
Member

sparkoo commented Nov 16, 2020

this is mostly operator issue with permissions. IMHO it is duplicate of this #15493 which even has open PR eclipse-che/che-operator#166 which I've started almost a year ago eclipse-che/che-operator#137 :)

I believe it was not done because it works on openshift with oauth and we don't want to have so wide permissions for che-operator. It's probably worth to revisit.

@sunix
Copy link
Contributor Author

sunix commented Nov 17, 2020

Thanks @sparkoo! Is the procedure with permission documented?

@sparkoo
Copy link
Member

sparkoo commented Nov 17, 2020

Thanks @sparkoo! Is the procedure with permission documented?

I don't think so and I agree that this should be at least documented. Something like "if you want to have namespace per user strategy, grant these cluster permissions ClusterRole blablabla to che SA and set server.workspaceNamespaceDefault:'che-<username>'"...

@sunix
Copy link
Contributor Author

sunix commented Nov 17, 2020

In my opinion, during installation, chectl should warn the user that namespace per user strategy couldn't be used because of ClusterRole permission. and link to the doc how to do it.
@l0rd WDYT?

@sparkoo
Copy link
Member

sparkoo commented Nov 17, 2020

@sunix I disagree with this. We should set our defaults to work as smooth as possible. Having a installer that by default does not install working product and link me to documentation is big UX flaw. We can add a warning to do some manual steps, but don't set such cases as defaults.

@sunix
Copy link
Contributor Author

sunix commented Dec 4, 2020

@sparkoo the user is expecting to have 1 namespace for all his workspace. This is recommended, and some features rely on it (for instance using user secrets) and we have to be consistent in all our installations as much as we can.

The installer should:

  1. check permission if it can use the 1 namespace per user strategy .
  2. If yes set the 1 namespace per user strategy
  3. If not, fallback to install the workspace in the che namespace, and warn the user how to do that whatever doc or in the warning message. But we should have it in the doc anyway.

I don't see any UX problem with that.

@che-bot
Copy link
Contributor

che-bot commented Jun 18, 2021

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.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 18, 2021
@skabashnyuk
Copy link
Contributor

Already implemented

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/che-server kind/bug Outline of a bug - must adhere to the bug report template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. severity/P2 Has a minor but important impact to the usage or development of the system.
Projects
None yet
Development

No branches or pull requests

5 participants