On 06/13/2012 04:28 AM, Dan Wendlandt wrote:
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
<mailto: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 agree. For the first phase polling should suffice. The RPC is a better
solution in the long run. I am in the process of setting up the
infrastructure for this. Once we have the common configuration support
we can import the RPC code from openstack common (I need to use this for
the scalable agents solution).
> 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 <http://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
