maxInstances :: Missing Env variable for the same in NodeFirefox

[pm-kedar-jedhe]

Hi Team,

There should be an env variable created which would set the value of maxInstances key from https://github.com/SeleniumHQ/docker-selenium/blob/master/NodeFirefox/config.json ?

[Davidsoff]

I do not agree, the docker philosophy means that you only run a single process in each container.
you can achieve the same by starting multiple firefox nodes and connecting them up to your hub

see this comment for a better explanation:#150 (comment)

[pm-kedar-jedhe]

Disagree with Option of having only one browser instance per node i.e. per container here.

#Below are few statistics.
Well if we look at the Layers on which selenium Grid node are running.
Image Overview::

1. Create Light weight Ubuntu machine.
2. Install Java
3. Install Selenium-grid
   and Then It creates one node having one instance of browsers reading selenium configuration properties

As per your comment we are saying just to create one more browser instance , create another node which goes over above mentioned steps again...

This is too much resource utilization of host Machine ...!!! For one more browser instance..!

Just by having maxInstances configurable and not keeping it hardcoded to 1..we might get the option of configuring containers per host machine capabilities. Which is true power of selenium-grid on machine resources front.

[nirvdrum]

FWIW, I agree with @pm-kedar-jedhe here. Requiring a Selenium Server instance per browser is a very heavy requirement and something we moved away from in the Selenium Grid 1.x -> 2.x upgrade.

I get the docker philosophy, but really we're just moving the goal post. By running the Selenium Server and a single browser, you've already violated the single process ideal. To be pure, what you'd probably want is that container to spawn a new container for each browser, which should be doable, but requires a lot of setup (sudo-less docker run, shared mounted docker socket, linked containers so the wire protocol can be spoken). At that point, you'd need to relax the 1 browser restriction in the config anyway.

[Davidsoff]

I agree that having a full ubuntu install on each container is heavy. If memory serves me right There is a PR to remove the ubuntu dependency and use Alpine Linux instead.

Would it work to start the containers with the browsers manually/using docker-compose and have those link with the selenium server? Then you would still need the max instances but they wouldn't be running in the same container

[nirvdrum]

Apologies if I wasn't clear, but this isn't about having the Ubuntu install. This is about the requirement of needing to run a new Java server (the node) for each browser, which is antithetical to the grid design.

I think what you're suggesting could work. But normally the node manages the browser session lifecycle. In my experience, trying to keep a browser hot by managing it outside creates all sorts of headaches. And I think the true value in docker here is being able to completely toss away the browser session state via the container lifecycle, which if I understand from your proposal, is compromised by keeping a static set of browser containers around.

While not the simplest thing in the world, the more I think about it, the more I think the node should spin up browsers in their own containers. The docker part is reasonably straightforward, if not tedious. But the browser launcher commands would need to be updated to handle spinning up the containers.

The other aspect to this that we haven't addressed is the node is responsible for resource management. It's expected a node can advertise more browsers than it can actually process. E.g., a node can advertise 5 Firefox, 5 Firefox ESR, and 5 Chrome, but also only 5 slots in total. This allows the hub to schedule any combination of 5 browser sessions on that node. By limiting the node to a single registered browser and running multiple nodes on the same machine, resource management would need to be done via a custom grid plugin.

Acknowledging all of this is rather messy, since there's two execution models with not-exactly-compatible designs, I'd be okay just allowing for multiple browsers running per session, but defaulting to 1. In that case, if someone needs to clear state, they could just restart the single node container.

[testphreak]

I'm sorry but I didn't understand the solutions proposed or the eventual commit by @ddavison. Perhaps I am missing the point. @pm-kedar-jedhe there is already a solution in place. I have been able to run more than 1 browser instance per container for a while now, by doing this -

My config.json

{
  "capabilities":
  [
    {
      "browserName": "firefox",
      "maxInstances": 3,
      "seleniumProtocol": "WebDriver"
    }
  ],
  "configuration":
  {
    "proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy",
    "maxSession": 3,
    "port": 5555,
    "register": true,
    "registerCycle": 5000,
    "hub": "http://localhost:4444"
  }
}

In the Compose file, I mount config.json -

selhub:
  image: selenium/hub
  ports:
    - 4444:4444

firefox:
  image: selenium/node-firefox
  privileged: true
  volumes:
    - ./firefoxConfig.json:/opt/selenium/config.json
  ports:
    - 5900
  links:
    - selhub:hub

So each node-firefox container in this case runs 3 instances of the browser.

Also @ddavison, what is Americium? See a bunch of files changed.

[ddavison]

see my note in your issue.