ovirt-quantum integration

[Dan Kenigsberg]

On Tue, Nov 27, 2012 at 05:12:32PM +0200, Gary Kotton wrote:
> On 11/27/2012 05:06 PM, Dan Kenigsberg wrote:
> >On Tue, Nov 27, 2012 at 04:43:52PM +0200, Gary Kotton wrote:
> >>On 11/27/2012 04:38 PM, Dan Kenigsberg wrote:
> >>>On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote:
> >>>
> >>>>>ix. I do not udnerstand the race when the VM starts. There is none.
> >>>>>When
> >>>>>a VM starts it will send a DHCP request. If it does not receive one
> >>>>>it
> >>>>>will send another after a timeout. Can you please explain the race?
> >>>>This is exactly it, the VM might start requesting DHCP lease before it was updated in the DHCP server, for us it's a race.
> >>>I think the point is that a guest dhclient may give up before Quantum
> >>>allocates it an IP. Maybe, due to timing and guests' behavior, the race
> >>>would not show up, but it is still there.
> >>Yes, this is certainly something that can happen if there are
> >>networking problems or if something in the system is broken. How is
> >>it done today in oVirt? Does someone has to go and manually update
> >>the DHCP server?
> >It's not done in oVirt, we want to gain it from Quantum...
> >Now you'd have to log into the guest and re-initiate dhclient (or
> >restart the guest) after manually configuring the DHCP server.
> 
> Quantum is certainly not perfect. It has a number of shortcomings
> but it does work. There are a number of major cloud providers that
> are using it and I do not recall them mentioning that they had
> problems with the timeout for the DHCP requests.
> 
> My two cents is that oVirt has a to gain by using Quantum. Quantum
> is moving fast - at the moment there is a lot of work being done
> with the addition of LBaaS. This is currently aimed at the end of
> the current release cycle.
> 
> This is a game changer for oVirt.

There is no doubt here about that. oVirt is far from perfect, and as a
first modest step towards perfection, we are going to use Quantum's
l3 address allocation - we just need learn to tame it.

> 
> >
> >>If the messaging is a real concern then you can piggyback to DHCP
> >>information on the RPC call to VDSM where the DHCP agent will be
> >>running. This will ensure that the information exists in the host
> >>file prior to running the VM.

On a second read, I'm not sure I understand your suggestion: do you
suggest to allocate the address with Quantum, send it to the destination
host on top of vmCreate verb, and pass it to a local instance on
dnsmasq? This would make Quantum's DHCP agent redundant, as well as the
newly-suggested setDHCP verb that's designed to turn it on.

Dan.