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

Selenium Grid Scaler should consider "maxSession" #2618

Closed
d-patch opened this issue Feb 9, 2022 · 12 comments · Fixed by #2774 or kedacore/keda-docs#716
Closed

Selenium Grid Scaler should consider "maxSession" #2618

d-patch opened this issue Feb 9, 2022 · 12 comments · Fixed by #2774 or kedacore/keda-docs#716
Assignees
Labels
feature-request All issues for new features that have not been committed to good first issue Good for newcomers help wanted Looking for support from community

Comments

@d-patch
Copy link

d-patch commented Feb 9, 2022

Proposal

The graphql API of Selenium Grid allows to query the "maxSession" value per grid and/or node:
https://www.selenium.dev/documentation/grid/advanced_features/graphql_support/#querying-the-number-of-maxsession-and-sessioncount-in-the-grid-
That is, if maxSession=5 each node can hold up to 5 concurrent sessions. Therefore, if there are 10 requests in the queue, only 2 nodes are neccessary to fulfill the requirements. Currently, the Selenium Grid Scaler of KEDA will scale up to 10 nodes in this case, ignoring the maxSessions per node.

Use-Case

No response

Anything else?

No response

@d-patch d-patch added feature-request All issues for new features that have not been committed to needs-discussion labels Feb 9, 2022
@zroubalik
Copy link
Member

Seems reasonable, are you willing to contribute this?

@d-patch
Copy link
Author

d-patch commented Feb 23, 2022

Sorry, but unfortunately I'm merely a user and not a developer.

@zroubalik zroubalik added good first issue Good for newcomers help wanted Looking for support from community and removed needs-discussion labels Feb 28, 2022
@adborroto
Copy link
Contributor

I can take this one.

@JorTurFer
Copy link
Member

Thanks a lot! ❤️

@amit337496
Copy link

@adborroto Any update on this issue

@adborroto
Copy link
Contributor

@adborroto Any update on this issue

PR open

@amit337496
Copy link

@JorTurFer / @adborroto I see this issue is closed... Is there any version we need to get this

@JorTurFer
Copy link
Member

Hi @amit337496
Next release will be during the first half of May. If you need to test this feature, you could use main tag, but we don't recommend it for prod environments because main is built every commit and could be not stable

@amit337496
Copy link

@JorTurFer Thank you.. I am able to see changes in 2.7 version.

How this scale down will happen in this scenario.. If node is still running will it kill that?

@JorTurFer
Copy link
Member

hi @amit337496
I'm not sure if I get your question. Do you mean how the scale in will be done?
If that's your question, KEDA doesn't take care about that because it's the HPA Controller who manages it. The HPA kills pods with task in progress, so your job could be interrupted. If you have use cases with long-running tasks or when your system doesn't retry non-acknowledge messages, you should use ScaledJob instead of ScaledObject.

@amit337496
Copy link

My scenario is I have 10 test cases and I set max nodes to 5. So it scaled up 5 servers and execution started... But for period of time scale down happened even if they are active sessions

@JorTurFer
Copy link
Member

Did you check ScaledJob? It, s the solution for long term processes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request All issues for new features that have not been committed to good first issue Good for newcomers help wanted Looking for support from community
Projects
Archived in project
5 participants