-
|
Hello: I deployed theia-cloud in a minikube container and found that the IDE container would be destroyed 30 minutes after it was no longer being used, even if the webpage of the IDE container was not closed. However, when I tried to replace the theia-cloud-demo image with my own image built with theia version 1.37 and successfully started it, the container did not automatically destroy itself even after I actively closed all the webpages. I tried to find out the logic in theia-cloud for determining whether an IDE container is still in use and for its automatic destruction, but the architectural documentation of theia-cloud only defines a session's timeout time in the App Definition CR. In the AppDefinitionSpec.java, I saw the Timeout class and the Monitor class, are these related to detection? Can you explain how theia-cloud determines whether an IDE container is still in use, and is it through the network traffic passed to the IDE container? Really appreciate! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
Does the monitor-theia is used to monitor the usage of theia ide container? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @inlann, there are currently 2 mechanisms to decide whether or not to shutdown a pod (note that you can use both at the same time):
The service running inside the pod is either a vscode-extension or a Theia extension installed in the application. You can take a look at the demo applications to see how this is done for the theia-cloud-demo. For what exactly is considered an activity you can take a look at the two extenions. The implementation is slightly different between the two due to the different capabilities that vscode and Theia extensions have. The behavior is of course customizable and you can provide your own extension that reports whatever you find suitable as an activity. Hope this helps. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sgraband, Really appreciate for you explanation! I reviewed all the source code of two extensions, monitor (a VSCode extension) and theia-monitor (a Theia extension). Both plugins listen to the mouse and keyboard events of users in their respective applications (VSCode and Theia) to determine if the application is still in use. Taking theia-monitor as an example, its backend module for the Theia backend process, namely the ExpressJS server, adds a GET request route: The frontend module of theia-monitor adds three window listeners - keydown, mousedown, and mousemove - upon initialization: This means that mouse and keyboard events in the Theia window are recorded by theia-monitor with timestamps in its own state. When an external GET request accesses I noticed that Java's operator module accesses this theia-monitor's It seems that this is the principle behind the Operator monitoring the state of the IDE container and destroying the session to terminate the IDE. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I found that the value of timeoutAfter, used in the pingSession function, is obtained from appDefinition, and this appDefinition is defined in theia-cloud-helm: The And in the However, in my cluster, the actual appdefinition CR (Custom Resource) displays the version as v1beta, which lacks the monitor field: $ kubectl -n theiacloud describe appdefinitions.theia.cloud theia-cloud-demo
Name: theia-cloud-demo
Namespace: theiacloud
Labels: app.kubernetes.io/managed-by=Helm
Annotations: meta.helm.sh/release-name: theia-cloud
meta.helm.sh/release-namespace: theiacloud
API Version: theia.cloud/v1beta
Kind: AppDefinition
Metadata:
Creation Timestamp: 2023-11-08T10:07:43Z
Generation: 5
Resource Version: 5478287
UID: 0e8583e3-9cd5-409f-877d-ac8f76a1dbd9
Spec:
Downlink Limit: 30000
Image: theiacloud/theia-cloud-demo:0.8.1.MS3
Ingressname: theia-cloud-demo-ws-ingress
Limits Cpu: 2
Limits Memory: 1200M
Max Instances: 10
Min Instances: 0
Name: theia-cloud-demo
Port: 3000
Requests Cpu: 100m
Requests Memory: 1000M
UID: 101
Uplink Limit: 30000
Events: <none>This absence prevents the operator from terminating the IDE container. My other question is, how is the actual appdefinition CR created, and based on what does it set its version? Additionally, I wonder if directly modifying its fields using kubectl edit -n theia-cloud appdefinition would reset its version. |
Beta Was this translation helpful? Give feedback.
-
|
Your assumption is correct, that the operator is the one who is pinging those endpoints and then decides when to shut down the pods. You always get the |
Beta Was this translation helpful? Give feedback.
-
|
BTW: I don't find the monitor-theia extension in Theia-Cloud official cluster:
or the vscode monitor extension:
Does this means that Theia-Cloud's official deployment does not use these two extensions? The versions of theia/core and theia/plugin in the dependencies of this plugin are still 1.34.0. If I want to use this plugin, do its dependency versions need to be updated along with Theia's own version? |
Beta Was this translation helpful? Give feedback.
-
|
The "official deployment" does not use the extension as it is limited to 30 minuted per pod anyway and we don't see a reason to use the monitoring there. In theory the Theia extension should still work with newer versions. However, we plan to update this according to the CR cycle of Theia, when we have time. |
Beta Was this translation helpful? Give feedback.
Your assumption is correct, that the operator is the one who is pinging those endpoints and then decides when to shut down the pods.
You always get the
v1betafield with kubectl because we currently have invalid version numbers (e.g.v8beta) and it will always default tov1beta. Note that the resource is still available asv8betaon the cluster, e.g. by changing your command tokubectl -n theiacloud describe appdefinitions.v8beta.theia.cloud theia-cloud-demo. We are planning to soonish update the version numbers to valid numbers (e.g.v1beta8). Then the default output of kubectl should be the latest version. Sorry for the inconvience.