Mapping Agents to multiple locations

Hey,

I’m trying to see if its possible to map an agent to more than a single location. For example, there would be a main pool that includes all agents, and another pool which would include a subset that includes agents from specific host that runs those VMs running the agents.
The end goal is to be able to run a test on the main pool that will run on all agents, and also be able to run a test on the subset pool which would obviously only run on those agents.

I’ve found a hacky way to do it by renaming all the agents from one host to the same name and using the tester param, but this is less than ideal as you lose the ability to run on a specific tester.
I’ve also tried using the “browser” to map to a set of agents, i.e. IE_OnHost1, IE_OnHost2. While this allows me to run tests on those custom browsers, when I try to run a test on simply IE, which is defined on both browser specific configs, only agents on config run the tests. It will not run the tests on all agents that support IE. By the way, all of this is with shard_tests = 1.

This seems like it should be possible, just judging from the testers on the public instance which seem to include the same agents on multiple locations, for example Dulles_MotoG and Dedicated_MotoG seem to contain the same agent. I guess it could also be a coincidence that the pc name and the ip are both the same.

You can add a “fallback” location ID in locations.ini to have the specific location fall back to the main pool when work isn’t available in the specific pool.

For example, the Dedicated_MotoG location has “fallback=Dulles_MotoG” and the logic to automatically check the other queues is handled on the server. It can actually support multiple fallbacks (comma-separated list) but I haven’t had a use for actually using more than one level of fallback.

The agents themselves can also poll for work from multiple locations by putting a comma-separated list in wptdriver.ini. In that case it will rotate between the locations in round-robin style. The Dulles Windows agents work that way so that Chrome and Firefox testing can come from a pool of devices that includes IE 10 and IE 11 machines.

The IE 10 machines have location=Dulles_IE10,Dulles and the IE 11 machines are location=Dulles_IE11,Dulles

Thank you! Saved me hours of headaches.

Interesting note for anyone else trying to do this, when using the UI, the last config listed in the location definition seems to always be chosen.
Defining my location like this:

[Production]
1=Win10ProdAgent
2=Host09
3=Host10
label=“Production Agents”

Results in all tests ran on Host10 config. So to force UI to use the main pool, Win10ProdAgents, I just rearranged them.

[Production]
1=Host09
2=Host10
3=Win10ProdAgent
label=“Production Agents”

The API of course doesn’t have this problem as the specific location is provided.

Thanks again!

If you’re just using the device-specific locations from the API you probably don’t even need them in the [Production] section. The grouping should only be needed for the UI (though it may be needed to see it in the /gettesters UI). You can also just have another group with “hidden=1” that you stash all of them in which will hide it from the UI.