ovirt-quantum integration

[Gary Kotton]

On 11/27/2012 04:06 PM, Mike Kolesnik wrote:
> Thanks for the reply,
> Please see comments inline
>
> ----- Original Message -----
>> On 11/27/2012 03:01 PM, Livnat Peer wrote:
>>> Hi All,
>>> Mike Kolesnik and me have been working on a proposal for
>>> integrating
>>> quantum into oVirt in the past few weeks.
>>> We decided to focus our efforts on integrating with quantum
>>> services, we
>>> started with IP address management service.
>>>
>>> here is a link to our proposal:
>>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>>
>>> As usual comments are welcome,
>> Please see my comments below:
>>
>> i. The quantum diagram is incorrect. It is the same message queue
>> that
>> passes the notifications. This is done by a message broker. In RH we
>> are
>> supporting qpid and in the community upstream rabbitmq is used.
> I will fix the diagram accordingly

Thanks
>
>> ii. The DHCP agent is plugable. That is there may be more than one
>> implementation. At the moment only dnsmasq is support. There was a
>> company working on ISC upstream but they have stopped due to problem
>> they encountered.
>> iii. Layer 3 driver. This is incorrect. The layer 2 agent does the
>> network connectivity. The layer 3 agent provides floating IP support.
>> This is something that you may want to consider to. It is related to
>> IPAM
>> iv. I am not really sure I understand you picture with server B and
>> get/create network. This is not really what happens. If you want I
>> can
>> explain.
> We saw that the DHCP Agent is trying to create the network interface if it doesn't exist (in DeviceManager.setup which is called as part of "enable_dhcp_helper").
>
> If you want to elaborate on this, please do.

The DHCP agent will create a device that is used by the dnsmasq process. 
The creation is done according to a driver that is used for the 
underlying l2 implementation. It does not have anything to do the the 
layer 3 agent. It creates a network device and assigns it an IP address. 
The layer 2 agent (if there is one) will attach this device to the 
underlying virtual network.
Prior to doing anything the DHCP agent will create a quantum port on the 
subnet. This is how it receives its own IP address.

>
>> v. What do you mean by the "port is then part of the Quantum DB". Not
>> all plugins maintain a database.
> True but if it's not saved somewhere then how does the Agent know which IP to assign to which MAC?

The DHCP agent is notified by the Quantum service of a new port 
allocation. It is passed the port details - the mac address and the IP 
address. The plugin may not use a database that one can access. All of 
the interface to the data is done via the Quantum API. For example the NVP.

>
>> vi. I think that you are missing useful information about the subnets
>> and gateways. This is also a critical part of the IPAM. When a VM
>> sends
>> a DHCP request it not only gets and IP but it can also receive host
>> route information. This is very important.
> can you please elaborate on this?

When you reboot your computer at work you get access to the internet. 
This is done via DHCP. You get an IP address and all of the relevant 
routes configured. The port data has the 'host_routes' which is also 
used by the dnsmasq. There can be more than one route which is 
configured. The subnet contains the gateway IP.

>
>> vii. The DHCP agent dynamics are incorrect (l3 agent, write port
>> definitions etc.). One of the pain points is that the process is for
>> each quantum network. This is a scale issue and is being discussed
>> upstream.
> This is what we saw that happens in the code, if we are wrong please explain what is the right behaviour of the DHCP Agent.

For each network that has one or more subnets with DHCP support a 
dnsmasq process is created. Please see http://fpaste.org/IHbA/. Here I 
have two networks.

>
>> viii. Quantum does not require homogeneous  hardware. This is
>> incorrect.
>> There is something called a provider network that addresses this.
> Can you please elaborate?

When you create a network you can indicate which NIC connects to the 
outside world. If you look at 
http://wiki.openstack.org/ConfigureOpenvswitch then you will see the 
bridge mappings. This information is passed via the API.
>
>> 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.

This works. This is how DHCP is engineered. Can you please explain the 
problem? If you send a DHCP request and do not get a reply then you send 
one again. The timeout between requests is incremental.

I am not sure that we are on the same page when it comes to a race 
condition. I'd like you to clarify.
>
>> You do not need to consume Quantum to provide IPAM. You can just run
>> the
>> dnsmasq and make sure that its interface is connected to the virtual
>> network. This will provide you with the functionality that you are
>> looking for. If you want I go can over the dirty details. It will be
>> far
>> less time than consuming Quantum and you can achieve the same goal.
>> You
>> just need to be aware when the dnsmasq is running to sent the
>> updates.
>>
>> IPAM is one of the many features that Quantum has to offer. It will
>> certain
>> help oVirt.
>>
>> Thanks
>> Gary