On 05/21/2012 05:27 AM, Daniel P. Berrange wrote: > We have mentioned a 1.0 release in passing a few times recently but we > have never really set out a clear list of goals for such a notable > release. This thread is an attempt to clarify such goals. To avoid > making the 1.0 target too hard, we should aim for as *little* as > possible on our TODO list. I think the priority here should be on public > API level things, or core libvirt infrastructure, and not random impl > details of specific hypervisors. In particular I think we should focus > on things that make libvirt better to develop app against. > > > - Lifecycle events for all top level objects About lifecycle events - your recent patches adding a few new hooks were very useful. I can see at least one other place that I think warrants a hook (and an event) - Stefan's DHCP snooping patch will allow libvirt to learn the IP address of a guest, which could be important to have in some sort of external action related to the guest. It would be good if there was a hook called (and event generated) any time this new code detected a DHCP lease being acquired or expiring (more generically, I guess any time a libvirt-detectable change in a guest's network config/status was encountered). > > https://bugzilla.redhat.com/show_bug.cgi?id=636027 > > * virConnectInterfaceEventRegisterAny Interesting. Somehow I'd never seen this BZ before. For the case of virInterface, I have plans to add some sort of event API to netcf that will notify registrants when the host interface config changes, and could be used to feed interface events (this new netcf API is necessary to write a working NetworkManager plugin using netcf). > Do you have suggestions for anything else that you think is very > important for libvirt ? In order for gnome boxes (and similar management applications that use qemu:///session) to give guests reasonable network devices, we need to make all of the qemu:///system network types (including defined networks, macvtap, openvswitch bridges) available to qemu:///session (after getting past policykit). Upstream qemu now has a setuid binary to do this for basic host bridges, but this is only a small subset of what libvirt supports, and uses file-based ACLs rather than policykit to control who is allowed to create the network devices. Oh, and also, it requires that qemu be installed (I guess I forgot to mention that this should work for lxc too, implying that qemu may missing from the host). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list