Open Stack

Hi operators, 

I wanted to ask for feedback on a design issue regarding DHCP agent and IP per
agent. 

So a short introduction first - I want to propose a spec to have a distributed
DHCP agent that can run directly on the compute node, and service only the VMs
running locally on it. 
This will help balance out the DHCP agent accross the cloud and each node will
only get the information it requires (no more MB size messages which get the
queue stuck). 
It will also limit the scope of failure of the DHCP agent and/or service to
that compute node alone. 

Now, regarding the IP consumption there are two possible alternatives: 
1. Use single IP per serviced subnet for all the servers. (similar to DVR) 
2. Use IP per server per subnet per host where VMs are serviced. 

So in a theoretical cloud with 100 running VMs for 10 subnets and 10 compute
nodes, per subnet the 1st approach will take only 1 IP while the second will
take a minimum of 1 IP and a maximum of 10 (limited by amount of compute nodes).

Now, I know the 1st solution seems very appealing but thinking of it further
reveals very serious limitations: 
* No HA for DHCP agents is possible (more prone to certain race conditions). 
* DHCP IP can't be reached from outside the cloud. 
* You will just see a single port per subnet in Neutron, without granularity of
the host binding (but perhaps it's not that bad). 
* This solution will be tied initially only to OVS mechanism driver, each other
driver or 3rd party plugin will have to support it individually in some way. 

So basically my question is - which solution would you prefer as a cloud op? 

Is it that bad to consume more than 1 IP, given that we're talking about private
isolated networks? 

Regards,
Mike