[libvirt] [RFC] The Quest for Domain-IP Mapping Continues...
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 would prefer OP1. What do you guys think? -- Nehal J Wani
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 5, 2014 at 3:33 PM, Daniel P. Berrange <berrange@redhat.com> 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? Or Should I send a patch only for qemuAgentGetInterfaces (and testcases) first?
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 :|
-- Nehal J Wani
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@redhat.com> 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. 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 5, 2014 at 4:33 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
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@redhat.com> 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.
The patch series is ready, but I have one question: From a developer's point of view, what should happen, when more than one flag is specified? (We can mention that the results can be ambiguous from user's point of view). Intuition says that the results should be combined. Options (virHashTable): (i) Should we use interface name as the key? (ii) Should we use the mac address as the key? Or should we just say that at one time, only one flag is supported? -- Nehal J Wani
On 12/14/2014 03:08 PM, Nehal J Wani wrote:
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.
The patch series is ready, but I have one question: From a developer's point of view, what should happen, when more than one flag is specified? (We can mention that the results can be ambiguous from user's point of view). Intuition says that the results should be combined. Options (virHashTable): (i) Should we use interface name as the key? (ii) Should we use the mac address as the key? Or should we just say that at one time, only one flag is supported?
What is the exact API you are proposing? If you use flags (1, 2, 4, 8), then one possible semantic is that specifying multiple flags at once allows the implementation to pick which method it uses (or that it tries multiple methods until one succeeds, but you don't know which one); if the caller cares about knowing which one succeeds, then they must not mix flags. The other alternative is to have a separate parameter from the flags, where that value is the method; here, you would number your methods 0, 1, 2, 3, and have a _LAST member in the enum in case we later add other methods. But without seeing the proposed signature of the new API, I'm not sure which way to lean. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Nehal J Wani