Clustering (was Re: Feature requests (somewhat long))

[Ade Lovett]

Oliver Lehmann wrote:
> Right now build names are tinderbox-universe wide and not host related.
> That means for having that we need a way of defining which build is
> running on which host (where host can be > 1). If you have the same build
> on more than 1 machine, and you want to run the test on a specific
> machine of one of those just specify the queueentry for the specific
> host. If you want to specify it for the build and the next "empty"
> machine which has this build configured the actual db-scheme neds to be
> enhanced.

The schema will definitely need to be extended to allow for this.  I'm
thinking of something along the lines of the following:

Add an "architecture" entry for jails, inherited by builds. (i386/amd64
etc.)

A "hosts" table, specifying:

	machine name (as the index key, and used by the web UI)
	machine hostname/address
	architecture
	connection characteristics (eg: "tinderd/tcp")
	list of available builds

Then a new "tc" command, "attachBuild/detachBuild", which would perform
sanity checking (ensuring that the architecture of the build and the
host are the same), and then add to the list.

Then a second new table "cluster", specifying:

	cluster name (as the index key, and used by the web UI)
	a list of {host,build} pairs

All the existing 'build' operations on "builds" (addPorts, tinderbuild,
www-exp port queueing, etc.) would then be moved over to operating on
clusters.

Current functionality (one build host, and a number of builds), would
require a little extra work to set up, namely the addition of a single
"localhost" host entry, and adding the builds to that host, but allowing
for multiple backend-host operations.

-aDe