-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add 'platformName' to selenium-grid scaler metadata structure #4038
Comments
Hi, I don't understand the part of |
Yeah, It's right.
As it is necessary to associate the /dev/kvm device to the pod so that it can be possible to run a virtual machine inside the container, what procedure would you recommend for such a configuration? |
No no, I'm not saying that the way isn't that, I'm just saying that KEDA doesn't manage it. KEDA just scaler the workload you want, but you need to define it by yourself, you can define your Deployment with that association in it's needed, and then deploy a ScaledObject to scale that Deployment, KEDA will generate an HPA and your Deployment will be scaled, but KEDA doesn't know anything about the associations of your deployment. I mean, KEDA won't access to the node and do anything, KEDA just generates the HPA and the metrics for that HPA |
WRT adding the parameter, it's totally feasible, if that parameter can be used for filtering we can introduce it :) |
Ok, I understand.
Yes, I intend to be contributing to this in the future. I won't start right away because this activity is not a priority at the moment and therefore I ask you to keep this issue open. |
Selenium grid scaler updated in #4105 and docs in kedacore/keda-docs#1039 |
Can this issue be closed now? |
Proposal
Currently, the selenium grid scaler only supports browserName and browserVersion capabilities in trigger metadata. This results in the impossibility of configuring a trigger for tests targeting specific platforms like Windows 10, Windows 11, etc.
Use-Case
If the platformName capability were supported it would be possible to configure a trigger like this:
Anything else?
The possibility of defining the platformName would make sense if it were possible to run a virtual machine, equivalent to the platform defined in the capability platformName, in the pod. In Linux this is possible through the native feature called KVM (Kernel-based Virtual Machine). That is, the operating strategy would be to make this resource available to the linux container (through /dev/kvm) and within the container use qemu, for example, to run the virtual machine.
The text was updated successfully, but these errors were encountered: