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.molinari@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.molinari@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~