Sessions Handling

[CarlosIVI]

Hello,

I've been working on Theiacloud and I found a behavior that I want to change, after login and having a Session with a Workspace, if I just closed my browser and try to get me to my session it says I have reached the limit of my sessions and I would have to wait until the timeout time is completed or kill the session using admin.

I would like to kill the session after closing the browser, so I can just login again and get another one, is there any parameter I can use in order to have this behavior?

Thank you

[jfaltermeier]

Hi,

Regarding stopping the session on browser close. We don't have this exact functionality, but we have a monitor functionality, that checks whether the user is still active. If not the user will be warned via a popup, that the sessions is stopped soon. If there is still no reaction the sessions will be stopped.
In order to use this you have to add a vs code extension to your application:
https://github.com/eclipsesource/theia-cloud/tree/main/node/monitor
and configure the monitor via helm:
https://github.com/eclipsesource/theia-cloud/blob/f984b4b406b57b9f68c6c26f6e52d3f53d0965dd/helm/theia.cloud/valuesMonitor.yaml#L44
We are also working on a Theia Extension, that may be used after #227 is merged.

Regarding going to the launching page again with an existing session:
I think when using workspaces with ephemeralStorage: false and the theia-cloud-try-now-page you should not get a new session, but back to your running session.
When no workspaces are used with ephemeralStorage: true, then the theia-cloud-try-now-page attempts to start new sessions.
But in the end our landing pages are just samples.
We offer an OpenAPI specification for the Rest API here: https://github.com/eclipsesource/theia-cloud/blob/main/doc/docs/openapi.json
And a common node API https://github.com/eclipsesource/theia-cloud/tree/main/node/common that may be used to communicate with the Rest API.
You may use this to get your own landing page that offers the features as you need them.

[CarlosIVI]

Thanks for the response. I have another question

After disabling ephemeral storage, TheIACloud Deployment for a new user start reaching for Persistence Volumes.
Leading to this error:
Warning FailedScheduling 2m58s default-scheduler 0/2 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod..

Does TheIAcloud creates their own PV? or should I provide a mechanism to create them with a new workspace/session?
Also I would like to know if is possible to keep the persistence folder from a Workspace and retrieve every time you login (Without keeping the session active)

[jfaltermeier]

Theia Cloud has three custom resources
AppDefinition - describes the app itself
Workspace - describes persistent storage
Sessions - brings together user, app definition, and workspace

When you disable ephemeral storage, then you should see that a workspace resource is created (kubectl -n yournamespace get workspaces). This will trigger the creation of a persistent volume and persistent volume claim. The storage will be mounted at the path specified in the app definition's mountPath property. The stored data is kept as long as the workspace custom resource lives and can be mounted again, by specifying the same workspace again in a session.

At the moment we have two implementations for creating persistent volume claims (a Default one and one for Minikube):
https://github.com/eclipsesource/theia-cloud/blob/f984b4b406b57b9f68c6c26f6e52d3f53d0965dd/java/operator/org.eclipse.theia.cloud.operator/src/main/java/org/eclipse/theia/cloud/operator/handler/impl/DefaultPersistentVolumeCreator.java#L43
https://github.com/eclipsesource/theia-cloud/blob/f984b4b406b57b9f68c6c26f6e52d3f53d0965dd/java/operator/org.eclipse.theia.cloud.operator/src/main/java/org/eclipse/theia/cloud/operator/handler/impl/MinikubePersistentVolumeCreator.java

Which one is used depends on the cloudProvider value in the helm chart: https://github.com/eclipsesource/theia-cloud-helm/blob/eb2b07702c17068621e380daca1cde81526f050b/charts/theia.cloud/values.yaml#L169

The default provider will just create a persistent volume claim relying on the cluster to auto provision a persistent volume for it.
The storage class of this claim can be configured via helm: https://github.com/eclipsesource/theia-cloud-helm/blob/eb2b07702c17068621e380daca1cde81526f050b/charts/theia.cloud/values.yaml#L187

The Minikube implementation will create a PV as well, because there is no auto provisioning.

[CarlosIVI]

Thanks for your quick answer @jfaltermeier, one last question

I can't find a way to enable the Try-now page, I couldn't find any Flag on the Helm Chart related to It and I'm not sure if this try-now page (Which only display a github Login button)

In order to make it work do I need to setup something additional on Keycloak? or maybe disable Keycloak?

Thank you

[jfaltermeier]

You can exchange the landing page in helm by specifying the docker image to use.

landingPage:
  image: theiacloud/theia-cloud-landing-page:0.8.1.MS1

landingPage:
  image: theiacloud/theia-cloud-try-now-page:0.8.1.MS1