-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
🚧 Propagate default ephemeral mode value #15713
🚧 Propagate default ephemeral mode value #15713
Conversation
Signed-off-by: Sergii Leshchenko <[email protected]>
Can one of the admins verify this patch? |
...-core-api-workspace/src/main/java/org/eclipse/che/api/workspace/server/WorkspaceService.java
Outdated
Show resolved
Hide resolved
To comment your question, I definitely vote for setting the value explicitly from the dashboard. If user does not click on the toggle, there is still some value set, so we can't get into some undefined state here. And as you said, we avoid some hidden unexpected behavior and possible inconsistencies between dashboard and server. |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
E2E tests of Eclipse Che Multiuser on OCP has failed:
|
vote for setting the value explicitly |
...-core-api-workspace/src/main/java/org/eclipse/che/api/workspace/server/WorkspaceService.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Sergii Leshchenko <[email protected]>
956d17c
to
03e6439
Compare
assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties
Outdated
Show resolved
Hide resolved
Signed-off-by: Sergii Leshchenko <[email protected]>
assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties
Show resolved
Hide resolved
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
E2E tests of Eclipse Che Multiuser on OCP has been successful:
|
public boolean isEphemeral(Map<String, String> workspaceAttributes) { | ||
String persistVolumes = workspaceAttributes.get(PERSIST_VOLUMES_ATTRIBUTE); | ||
if (persistVolumes == null) { | ||
return !defaultPersistVolumes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is the logic we want to go with -- I'd propose
- If
persistVolumes
is not present, assumed default value is true. - Only use ephemeral mode when
persistVolumes
is explicitly false.
This avoids the need to set it explicitly in all devfiles, and avoids breaking existing workspaces by disconnecting them from existing PVCs.
On the workspace creation side (e.g. in the dashboard), this would be handled by explicitly setting persistVolumes: false
if necessary, and leaving it out of the devfile otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put another way: if
che.workspace.persist_volumes.default=false
, any workspaces created will additionally havepersistVolumes: false
in their devfiles upon creation.che.workspace.persist_volumes.default=true
, workspaces don't get an addedpersistVolumes
field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to give an ability for Che Admin to configure default behavior of persisting volumes...
AFAIU you propose to keep the current Che Server logic where explicit value is used or volumes are persisted by default and only propagate default value to be consumed by clients like Dashboard.
I agree that it's safer in the perspective of existing workspaces without explicit values, where users do not expect changing behavior.
On another hand, Che Admin configured value won't be set to all workspaces by default, even new if workspaces are created with another client but not Dashboard - like chectl, or factory(if the value is not set explicitly in devfile).
I'm OK with the proposed alternative way since it's a lighter way that does not change the current Che Server behavior and at the same time allows us to configure Dashboard behavior via Che Server configuration.
I believe we need to reevaluate this pr.
Being late to the discussion as usual - I think the che server admin should have the ability to force all the workspaces to be ephemeral. Consider a "playground" che installation where really nothing should ever be stored because it is just for "fooling around". But maybe that would better be done differently than providing a default value for an ephemeral mode. Maybe we could have a permission to create (non-)ephemeral workspaces that admin could grant to users? |
@metlos I think #15775 supersedes this PR. On the topic of allowing an admin to force ephemeral mode, I think it creates too many edge cases to be something we want to support:
The difference between ephemeral and non-ephemeral is significant enough that I think it should be stored explicitly in devfiles. |
The alternative solution is already merged in #15775 |
What does this PR do?
🚧 It's suspended in favor of #15775
In the scope of issue about configurable Dashboard #15462, the default value of ephemeral mode should be configurable as well.
But Che Server already contains hard-coded behavior for persistVolumes (it's true), that can be overridden with the corresponding attribute on workspace level.
It makes more sense to make Dashboard consume Che Server default instead of configuring a separate default for it.
So, this PR makes Che Server propagating default ephemeral mode value.
Open question: to avoid reconfiguring existing workspaces, Dashboard must set default value explicitly (even if the user does not click on the toggle at all)
What issues does this PR fix or reference?
#15462