[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFC: TODO list for a 1.0 release

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]