[🚀 Feature]: Killing Sessions via UI
shmikkil opened this issue · 19 comments
Feature and motivation
We are using k8s grid 4 and have the pods up and running all the time. It's a hassle to delete the pods that're stuck when sessions time out or when end-users doesn't close their sessions after the tests were executed. Any way we can add this feature to delete/remove sessions via the UI Console by right-clicking each of these sessions and remove them? Thank You!
Usage example
Right click on individual session IDs that are long running and delete/remove them.
@shmikkil, thank you for creating this issue. We will troubleshoot it as soon as we can.
Info for maintainers
Triage this issue by using labels.
If information is missing, add a helpful comment and then I-issue-template label.
If the issue is a question, add the I-question label.
If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.
If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C),
add the applicable G-* label, and it will provide the correct link and auto-close the
issue.
After troubleshooting the issue, please add the R-awaiting answer label.
Thank you!
This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.
Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.
This issue is looking for contributors.
Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested.
This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.
Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.
Awesome...Glad to hear that! And yes, just going with a default pwd at the moment. Come to think of it, perhaps we should have another enhancement request where there should be an ability for the admins to assign creds to a specific group that could delete/maintain while the end-users who run the tests to be assigned to another group that simply can access the sessions during runtime to view the execution via the UI as well. Would that be helpful?
This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.
Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.Awesome...Glad to hear that! And yes, just going with a default pwd at the moment. Come to think of it, perhaps we should have another enhancement request where there should be an ability for the admins to assign creds to a specific group that could delete/maintain while the end-users who run the tests to be assigned to another group that simply can access the sessions during runtime to view the execution via the UI as well. Would that be helpful?
I do not think Grid should start managing user profiles and passwords, that requires storage and managing those credentials very carefully. For now, Grid offers basic auth with a single user and password. That type of feature is out of scope.
This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.
Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.Awesome...Glad to hear that! And yes, just going with a default pwd at the moment. Come to think of it, perhaps we should have another enhancement request where there should be an ability for the admins to assign creds to a specific group that could delete/maintain while the end-users who run the tests to be assigned to another group that simply can access the sessions during runtime to view the execution via the UI as well. Would that be helpful?
I do not think Grid should start managing user profiles and passwords, that requires storage and managing those credentials very carefully. For now, Grid offers basic auth with a single user and password. That type of feature is out of scope.
Thanks for the clarification!
@diemol - Basic question around this. If a session is stuck due to whatever reasons (for e.g., the client died/was killed) then wouldn't the session eventually timeout because the guava cache in LocalNode has a listener which seems to be triggering a delete session request for sessions that are about to be evicted.
- If this cleanup logic is assumed to be reliable (things can still go wrong when we attempted to fire a POST request to delete session) then when would we need this sort of an explicit cleanup ?
- Even if we were to provide that mechanism (by having the user call the delete session API) would that work because our cleanup would have cleaned up the slot to which this session was associated with ?
@krmahadevan yes, eventually the timeout will kick in and stop the session.
If this cleanup logic is assumed to be reliable (things can still go wrong when we attempted to fire a POST request to delete session) then when would we need this sort of an explicit cleanup ?
I see as the use case where a session was started with the wrong parameters and you do not want to wait until the timeout kicks in. An Appium session for example.
Even if we were to provide that mechanism (by having the user call the delete session API) would that work because our cleanup would have cleaned up the slot to which this session was associated with ?
The cleanup mechanism for timeout only kicks in when the timeout happens, so this new feature would just be a nice thing to have when one wants to stop the session.
I see as the use case where a session was started with the wrong parameters and you do not want to wait until the timeout kicks in. An Appium session for example.
Ok. In that case, it would just boil down to invoking the DELETE session api (endpoint: /se/grid/node/session/{sessionId}, operation: DELETE) via a curl right ?
I see as the use case where a session was started with the wrong parameters and you do not want to wait until the timeout kicks in. An Appium session for example.
Ok. In that case, it would just boil down to invoking the DELETE session api (endpoint:
/se/grid/node/session/{sessionId}, operation:DELETE) via a curl right ?
That also works. However, the idea would be to have it as an option from the UI (under a flag or so).