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 _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
