Instead of choosing servers directly, you can set up data to describe the right kind of server for a project or step.
You create collectors to attach properties to servers, and those properties are stored as the server's manifest. You define selectors to specify desired properties for a project or step. Server manifests allow the system to choose the right server for a project or step dynamically, based on the current situation.
Simple Example: You create a selector named Mercury which selects servers whose BF_NAME is equal to Mercury. When you run the project, the system selects the server named Mercury. Because this property is unique, the system always chooses the same server, and if that server is not available, the project fails for lack of an available server.
More Complex Example: You create a collector named Stats that collects RAM, number of CPUs, and hard-disk space available. You assign the collector to several servers, one named Mercury (with 512MB RAM), one named Mars (with 1GB RAM), and one named Jupiter (3GB RAM). Then you create two selectors named MuchRam (which selects servers with at least 2GB RAM) and NotMuchRam (which selects servers with at least 256MB RAM). Finally you create two projects, each of which uses one of these selectors.
When you run the projects, the system chooses the server Jupiter for the project that uses the MuchRam selector, because it is the only one that matches. The project that uses the NotMuchRam selector may end up with any of the available servers.
Later you add a server, Neptune (2GB RAM), to the system. The next time you run a project that uses the MuchRam selector, the system may choose either Neptune or Jupiter. If Jupiter is down for some reason, the system uses Neptune, as it is the only one left that fits the selector.