Open Stack

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

Very happy about dev's coming here for input :)


> 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).

If I understand correctly taking an IP (potentially) by the number of hypervisors can quickly go to insane proportions. 
A one on one ratio would not be so far fetched for a cloud with a significant amount of hypervisors.
For us the current "standard" /24 would become smallish...
Also when live-migrating machines to a different hypervisor you could run out if IP's for the DHCP servers...

> 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.

The thing that worries me the most is the implementation in the OVS mechanism driver.
I'd needs to be very well documented that you might not get feature parity with different drivers.

>So basically my question is - which solution would you prefer as a cloud op?
As others before me I also lean toward option one.


Cheers,
Robert van leeuwen