On Fri, Dec 05, 2014 at 12:20:03AM +0530, Nehal J Wani wrote: > If you remember correctly, about 1.2 years ago, we had... > https://www.redhat.com/archives/libvir-list/2013-September/msg00351.html > > In short, the patch proposed a generalized mechanism for finding out > IP addresses, with flags for choosing method(s) (SNOOP|LEASE|AGENT). > > But since not all methods were supported (only qemu-ga worked), the > API was deferred. > > After exploring a bit, it seems that in all, we can have: > (i) Leases Method > (ii) Qemu Guest Agent > (iiI) DHCP Snooping (exists, but isn't publicly exposed?) > (iv) ARP Snooping (we can ask the virtual network interfaces to share > their arp tables with the public?) > > Now that we have the dhcp-leases API fully furnished, why not visit > the qemu-guest-agent again? > > OP1. Should we have separate APIs + virsh commands for each one of > these and then combine them together under > virDomainInterfaceAddresses? > - If each one has to be a different API and then combined later, then > what should be the corresponding name for the virsh command for > exposing the querying guest agent API? > OP2. Implement virDomainInterfaceAddresses API with two flags, one for > dhcp-leases and another for qemu-ga and keep adding others whenever > they are completed? I don't see any real reason to have separate APIs for each method. The API signature will be the same in all cases, so having a single virDomainGetInterfaceAddrs() method with a bunch of flags to control what data source is used is preferrable. I'd expect the DHCP leases method to be used as the default, since that's the most likely method to succeed in the common case.

Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Fri, Dec 05, 2014 at 04:28:10PM +0530, Nehal J Wani wrote: > On Fri, Dec 5, 2014 at 3:33 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: > > On Fri, Dec 05, 2014 at 12:20:03AM +0530, Nehal J Wani wrote: > >> If you remember correctly, about 1.2 years ago, we had... > >> https://www.redhat.com/archives/libvir-list/2013-September/msg00351.html > >> > >> In short, the patch proposed a generalized mechanism for finding out > >> IP addresses, with flags for choosing method(s) (SNOOP|LEASE|AGENT). > >> > >> But since not all methods were supported (only qemu-ga worked), the > >> API was deferred. > >> > >> After exploring a bit, it seems that in all, we can have: > >> (i) Leases Method > >> (ii) Qemu Guest Agent > >> (iiI) DHCP Snooping (exists, but isn't publicly exposed?) > >> (iv) ARP Snooping (we can ask the virtual network interfaces to share > >> their arp tables with the public?) > >> > >> Now that we have the dhcp-leases API fully furnished, why not visit > >> the qemu-guest-agent again? > >> > >> OP1. Should we have separate APIs + virsh commands for each one of > >> these and then combine them together under > >> virDomainInterfaceAddresses? > >> - If each one has to be a different API and then combined later, then > >> what should be the corresponding name for the virsh command for > >> exposing the querying guest agent API? > >> OP2. Implement virDomainInterfaceAddresses API with two flags, one for > >> dhcp-leases and another for qemu-ga and keep adding others whenever > >> they are completed? > > > > I don't see any real reason to have separate APIs for each method. > > The API signature will be the same in all cases, so having a single > > virDomainGetInterfaceAddrs() method with a bunch of flags to control > > what data source is used is preferrable. I'd expect the DHCP leases > > method to be used as the default, since that's the most likely method > > to succeed in the common case. > > So, should I go ahead and redo that patch, with two flags enabled? I think yuou should redo that patch series adding the DHCP lease support, since that's the reason we didn't merge that code last time around.