ovirt-quantum integration

[Gary Kotton]

On 11/27/2012 06:08 PM, Dan Kenigsberg wrote:
> 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.

Not sure that tame it is the correct terminology. It is not clear how 
one will be able to take certain parts of Quantum. But that is another 
issue.
>
>>>> 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.

I am not familiar with the verb setDHCP. The DHCP agent manages a 
dbsmasq class. You can make use of this directly in VDSM where you 
control the updates of the DHCP data and the launching of the VM. This 
is a hybrid of Quantum and oVirt/VDSM (this is #3 below)

I think that you have a number of options and I'd like to elaborate:
1. Consume Quantum as it is (with the good and the bad).
2. Consume building blocks of of Quantum and wrap certain interfaces 
with oVirt/VDSM proprietary implementations (say for example instead of 
using a messge broker, make use of the RPC commands that you have 
today). In OpenStack there is a common RPC library. You can leverage 
this interface to have more control over what happens and when.
3. Forget Quantum and build it yourself using ideas and lessons from Quantum

My leanings would be for #1 but it would certainly be worthwhile looking 
into #2. Maybe with little effort you can use existing API's and have 
the best of both worlds.


>
> Dan.