In an IRC chat, Brian and I were discussing the idea of per-host configuration and how it could work. A couple things that came up:
- Per-host configuration could be produced by each host and consumed by the domain controller (DC), as opposed to the domain configuration which is produced by the DC and consumed by the hosts.
- This implies that the host configuration is separate; so each host will have a domain.xml and a host.xml, and the DC will have the master domain.xml plus one host.xml for every host it knows about.
- The DC should be able to perform admin operations against hosts; however in the event a known host is down or unavailable, the per host management operations for that host may be read-only; alternatively, a strategy may be worked out to merge configurations when the host comes back on line (this is more complex though).
- Requirement: a user should be able to copy an installed image from one host to another and start it up without any unexpected behavior.
- Requirement: we should have a way to create a "bootstrap" environment, which would consist of an installed image with a server configured which acts as the DC. (This is working on the assumption that the DC is a server role of some sort.)
- The host configuration contains a list of servers to start, each of which is assigned to a server group. This is where any JVM configuration will go, as well as any OS-specific stuff (setting "nice" values, CPU or other resource affinity, etc).
- The host configuration contains mapping of domain concepts (i.e. named network interfaces) to physical resources (i.e. an actual IP address). Note that the IP address case needs some additional discussion (i.e. Bela's cloud case where the IP is detected somehow).
- The service binding manager-equivalent service will be involved in ensuring a distinct network configuration for each server.
There's still more to figure out but I think this is the basic framework we're dealing with.