ovirt-quantum integration

[Mike Kolesnik]

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

> 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.

> 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?

> 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?

> 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.

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

Can you please elaborate?

> 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.

> 
> 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