Thanks for responding Willian! Looping in main list in case others are interested in progress. A few comments inline.
Dan On Tue, Jun 12, 2012 at 6:13 PM, Willian Molinari < willian.molin...@locaweb.com.br> wrote: > Æ!! > > We were waiting for a definition from Mark / Carl but I think we should > start some discussions (as Dan mentioned before) sooner as possible. > I'm just concerned because we are not working diretly with nova (we have > our own in house solution for compute), so we may not understand some needs. > > > 1) take the dnsmasq + vif-plugging logic currently in > nova/network/linux_net.py and create a library in quantum/agent/linux > (similar to how we're moving the iptables_manager class there..) > > I agree. I don't know the nova/network/linux_net.py code but I think it > looks like the code we are migrating to the iptables_manager and will be a > good start for different dhcp backends. > great. > > > 2) create a dhcp-agent that can run on a centralized node. It could > learn about new Quantum ports and their IP/MAC pairs by polling the > database (trivial to implement but slow) or via a notification API or RPC > (more efficient and more general). > > For each new network, it would use the quantum v2 client library to > create a port on that network and "vif-plug" a dnsmasq instance into that > network. For each new port on that network, it would fetch the MAC + IP > pair from Quantum, then update the DHCP config. > > Pooling would work. On our quantum branch (using that big plugin) we're > using rabbitmq to make the connection between our dhcp agent and quantum. > The agent consumes a queue and the server publish to it when a new vm needs > ip. > The API solution looks better but we'll need more code and maybe more time > to implement it IMHO. > I agree. Having some kind of notification is clearly the right way to scale this, but polling could be a simple short-cut to get this working for F-2. The logic is so simple that there's really no wasted work :) > > > I think there could also be a pretty simple "multi-host" variant of > this that runs on each hypervisor as well to eliminate any concerns around > HA for a centralized implementation. > > This implementation could even learn about new ports on the hypervisor > on its own by monitoring the vswitch itself. > > Is this second implementation critical for F-2? > No. A multi-host solution is important for the Folsom deliverable, so we need to target it for F-3, but for F-2 I think we just need any DHCP mechanism that is compatible with the IPs allocated by Quantum v2 API. > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
