Selenium grid v2 could have different configuration per slave

Details

Description

When running slaves with the selenium grid v2 plugin, each slave could have different configuration (some not supporting IE on linux, or not chrome). The suggestion here is to be able to configure the grid v2 configuration per slave. Not only on the master.

Richard Lavoie
added a comment - 2012-01-25 16:50 A configuration suggestion could be to have different configuration type, defaulting to "inherit from master"
Inherit from master (takes the config from the global jenkins manage configurations)
From config file
Specify config file (yaml or xml with detection of config type so the selenium proces starts with the right flag)
Manual flags configuration
Same fields as the current global configuration in jenkins "manage" page

Here are a few things that I would want to be able to do using the plug-in.

a. Customize the hub by passing in a configuration file (a yaml file so that the grid works parsing it Selenium1 grid mode), or a JSON file (Selenium2 grid mode)

b. Customize the node by passing in either a JSON configuration file (or) by passing command line arguments as well.

c. A provision to specify the chromedriver binary where it exists, because when a webdriver node is spawned, unless and until it is fed the chromedriver binary path, chrome executions may not work.

d. The grid has the capability to accept servlets which can be injected into it. So I would want a provision wherein I can provide a custom built jar that can be accepted by the plug-in, added to the classpath and then it be injected into the grid via the -servlets command arg.

e. The node has the capability to accept custom proxies (apart from the default proxy). I would want a provision wherein I can provide this as well.

f. Currently the plug-in works on by depending on a specific version of the selenium standalone jar. If there is a way to de-couple this plug-in and the jar it works with, it would give me the flexibility of upgrading the selenium2 dependency based on the selenium release and not warrant an updating of the plug-in.

I am pretty new to jenkins plug-in development and I have no clue as to how things work in general. If you have some time to walk me through on some basics, perhaps I can pitch in on this as well.

Krishnan Mahadevan
added a comment - 2012-02-08 07:52 Richard,
Here are a few things that I would want to be able to do using the plug-in.
a. Customize the hub by passing in a configuration file (a yaml file so that the grid works parsing it Selenium1 grid mode), or a JSON file (Selenium2 grid mode)
b. Customize the node by passing in either a JSON configuration file (or) by passing command line arguments as well.
c. A provision to specify the chromedriver binary where it exists, because when a webdriver node is spawned, unless and until it is fed the chromedriver binary path, chrome executions may not work.
d. The grid has the capability to accept servlets which can be injected into it. So I would want a provision wherein I can provide a custom built jar that can be accepted by the plug-in, added to the classpath and then it be injected into the grid via the -servlets command arg.
e. The node has the capability to accept custom proxies (apart from the default proxy). I would want a provision wherein I can provide this as well.
f. Currently the plug-in works on by depending on a specific version of the selenium standalone jar. If there is a way to de-couple this plug-in and the jar it works with, it would give me the flexibility of upgrading the selenium2 dependency based on the selenium release and not warrant an updating of the plug-in.
I am pretty new to jenkins plug-in development and I have no clue as to how things work in general. If you have some time to walk me through on some basics, perhaps I can pitch in on this as well.

Since I don't want to clutter the configuration UI, some configurations will only be available through the FileConfiguration, I'm talking about d and e here. This is some pretty advanced config which I doubt will be frequently used in jenkins.

A, B and C are going to be taken care of (b is done, a was not in my mind but easy to do, and e only needs to specify the path for chromedriver which is easy as well)

Richard Lavoie
added a comment - 2012-02-08 13:41 Thanks for the feedback.
Here is some precision about how these needs.
Since I don't want to clutter the configuration UI, some configurations will only be available through the FileConfiguration, I'm talking about d and e here. This is some pretty advanced config which I doubt will be frequently used in jenkins.
A, B and C are going to be taken care of (b is done, a was not in my mind but easy to do, and e only needs to specify the path for chromedriver which is easy as well)
F is behing handled by another issue, see https://issues.jenkins-ci.org/browse/JENKINS-12675
If you want to check the code I've done so far, you can take it from : https://github.com/darkrift/selenium-plugin
I'm fairly new to jenkins dev as well, started doing those changes 2 weeks ago but it's rather easy once you know the available parts in jenkins.
If you have anything else you want, please submit them.
Richard

Since the hub is running in jenkins directly, I don't see how this could be useful for one to specify it's servlets. Thinking about it, I even doubt it will work to add the custom jar to allow that just like you don't have the flexibility to specify your own CapabilityMatcher because it's jenkins that handles that ...

Maybe that needs to be thought about, but I don't see the use rather than using an independant grid for more complex configurations/specifications.

Richard Lavoie
added a comment - 2012-02-08 13:47 Can you just explain the goal of D ?
Since the hub is running in jenkins directly, I don't see how this could be useful for one to specify it's servlets. Thinking about it, I even doubt it will work to add the custom jar to allow that just like you don't have the flexibility to specify your own CapabilityMatcher because it's jenkins that handles that ...
Maybe that needs to be thought about, but I don't see the use rather than using an independant grid for more complex configurations/specifications.
What's your thoughts about it ?
Thanks
Richard

The goal of D would be to provide customization to the Grid.
Here are some scenarios wherein this will be useful.

a. I have a servlet that I have integrated with VNC, which provides me a way using which I can let my end users watch their automation on the actual remote machine.

b. I have a servlet which restricts nodes from registering themselves to my grid. Only nodes whose IP addresses are known to me would be allowed to register themselves with me.

c. I have a servlet that keeps track of how many tests were run on a particular node, before deciding to clean it up.

But yes, I agree completely with you. These are pretty complex configurations/specifications which not everyone would want to use. As such these are "Nice to have" features but not something that needs to be absolutely present in the plug-in.
So I think we can live with the fact that the Jenkins selenium plugin wouldnt provide for such features.

So for now D and E can be skipped and even then this plug-in would be an awesome way for end-users to make use of.

Btw, the following things came up to my mind when you asked me if I had any additional reqs.

Would jenkins inherently let me do the following ?

1. The grid (spawned by the selenium plug-in) hung and needs to be restarted. How do I accomplish that ?
2. One or more nodes (slaves in this case) got hung and needs to be restarted. How do I accomplish that ?

Pardon me for not paying attention to this thread. I was under the assumption that whenever any new comments got added, it would automatically trigger an email, which wasn't the case here
I will be more vigilant going forward.

And yes, I do want to take a look at your delivery, just to atleast get a feel of how jenkins development works in general and if possible provide some small contributions as well.

Krishnan Mahadevan
added a comment - 2012-02-13 05:37 Richard,
The goal of D would be to provide customization to the Grid.
Here are some scenarios wherein this will be useful.
a. I have a servlet that I have integrated with VNC, which provides me a way using which I can let my end users watch their automation on the actual remote machine.
b. I have a servlet which restricts nodes from registering themselves to my grid. Only nodes whose IP addresses are known to me would be allowed to register themselves with me.
c. I have a servlet that keeps track of how many tests were run on a particular node, before deciding to clean it up.
But yes, I agree completely with you. These are pretty complex configurations/specifications which not everyone would want to use. As such these are "Nice to have" features but not something that needs to be absolutely present in the plug-in.
So I think we can live with the fact that the Jenkins selenium plugin wouldnt provide for such features.
So for now D and E can be skipped and even then this plug-in would be an awesome way for end-users to make use of.
Btw, the following things came up to my mind when you asked me if I had any additional reqs.
Would jenkins inherently let me do the following ?
1. The grid (spawned by the selenium plug-in) hung and needs to be restarted. How do I accomplish that ?
2. One or more nodes (slaves in this case) got hung and needs to be restarted. How do I accomplish that ?
Pardon me for not paying attention to this thread. I was under the assumption that whenever any new comments got added, it would automatically trigger an email, which wasn't the case here
I will be more vigilant going forward.
And yes, I do want to take a look at your delivery, just to atleast get a feel of how jenkins development works in general and if possible provide some small contributions as well.
~Krishnan

Bala Naveen Reddy Kappeta
added a comment - 2012-03-06 06:37 - edited Hi Richard,
When can we expect this change would be done and updated to the plugin. I could do this through Selenium Grid now but waiting to configure my scripts to Jenkins
Or please provide some information if we have any workaround to start a user specified configuration for a slave
Thanks,
Bala

Richard Lavoie
added a comment - 2012-09-04 04:25 The latest version of the plugin (v2.1) now allows configurations for slaves with multiple running configurations per node as well.
They can also be started/stopped and restarted by the management page.