The heat template will presumably have to have knowledge of all of the different profiles a node could be, in order to lay down the correct template at node creation. Frankly, there could be other tunable parameters that vary by node profile too (I'm thinking sysctl, VM allotted RAM and CPUs, etc.). I'm assuming these can be contained in the heat template and broker can just request "node of profile X".

There are actually two kinds of capacity to watch - active capacity (basically, node capacity) and total capacity (basically, district capacity -- inactive gears still take up district space). The algorithm for determining where to add/remove nodes/districts is a little tricky (as in, no one has codified it yet - I plan to do this as an admin library for the admin console, should be able to leverage that) and may depend on other parameters, particularly expected idle rate.

All of this assumes districts. I think we should explicitly say that districts are required for this functionality.