On 10/06/2014 06:11 AM, Mike Kolesnik wrote:
On 10/06/2014 04:09 AM, Mike Kolesnik wrote:
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).
eventually they will be just bugs, bugs can be fixed
* DHCP IP can't be reached from outside the cloud.
that's a feature :)
* You will just see a single port per subnet in Neutron, without
granularity of
the host binding (but perhaps it's not that bad).
may be an issue for monitoring, i will have more ports deployed that
registered in my db.
i don't know if is *really* an issue, still does not sounds good
* 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?
option 2 is a no go for me, i can't waste that many ip
Is it that bad to consume more than 1 IP, given that we're talking about
private
isolated networks?
not always, all the vm we deploy in the prod environment have public ip,
they speak freely to the internet. no nat, no lbaas.
So basically the DHCP server is also consuming a public IP?
Yes. And, for the record, this is how nova-network in multi-host mode works.
Also since you're always using the public network, does distributing the
DHCP agents/servers sound interesting?
Yes, due to the spread out of the failure domain. As you point out, with
multi-host nova-network mode, each compute node has a DHCP server that
services the VMs on that particular compute node only. This means that a
centralized DHCP agent doesn't bring down IP assignment services across
a large swath of the deployment, which is a huge plus (and what DVR is
aiming for, IIRC)
Best,
-jay
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
