Welcome Guest! To enable all features please Login or Register.



Gridnode "Pool"
#1 Posted : Thursday, June 6, 2019 1:27:56 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/4/2018(UTC)
Posts: 2
Location: Germany

We use currently NCrunch with a lot of tests in our large solution.

To free the local machines resources we set up 3 gridnode servers.

This works fine but we expected a slightly different behavior.
We distribute the NCrunch settings via our repository. So every team member has all 3 gridnodes configured.

What we expected was having a pool of remote machines overtaking the tasks of running the tests, but instead every developer connects to every gridnode and runs his tests on every machine.

Is there some way to configure the system so that only one server from the pool is used, not all of them? Basically what we want is some kind of configuration that works like a webserver farm.
#2 Posted : Thursday, June 6, 2019 9:18:21 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,758

Thanks: 745 times
Was thanked: 956 time(s) in 911 post(s)
Hi, thanks for posting.

The structure you're after was considered early in the development of the grid system. Although there are advantages to it, it was rejected in favour of the current model for the following reasons:

1. A pool-based system doesn't allow the individual resources of nodes to be shared across multiple users. For example, if you have 6 users but 3 grid nodes, only 3 users would get a node, the rest would be left with no resources.
2. It's quite common that not all developers in a team will be writing code at the same time. If you have one of 6 developers working late at night, under the current model they enjoy full access to all grid resources with no machines sitting idle.
3. The system is designed to work with grid nodes of different hardware and software configurations. You might have both smaller and larger nodes. Running a pool-based system with such a setup would result in unfair distribution of grid resources.
4. DistributeByCapabilitiesAttribute, which can be used to split tests across nodes for multi-platform testing.
5. It's hard to efficiently manage a pool of resources without a central node to coordinate them. Right now we don't yet have the concept of a controller node (though this has been in the planning for a good long while now).

So basically, right now the product can't be configured to behave in the way you're expecting it to. However, what you can do is assign each of your developers to their own node in their own local configuration. If you have more developers than you have nodes, maybe some of them can share a node.
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.024 seconds.