[libvirt] RFC: TODO list for a 1.0 release

[Daniel P. Berrange]

On Mon, May 21, 2012 at 01:46:24PM +0200, Michal Privoznik wrote:
> On 21.05.2012 11:27, 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.
> > 
> > IMHO we should have the following things in the 1.0 release
> > 
> >  - List object APIs which directly return the object instance
> > 
> >     https://bugzilla.redhat.com/show_bug.cgi?id=636096
> > 
> >     * virConnectListAllDomains
> >     * virConnectListAllInterfaces
> >     * virConnectListAllNetworks
> >     * virConnectListAllNWFIlters
> >     * virConnectListAllNodeDevices
> >     * virConnectListAllSecrets
> >     * virConnectListAllStoragePools
> > 
> >     * virDomainListAllSnapshots
> > 
> >     * virStoragePoolListAllVolumes
> > 
> >    NB: with support across LXC, UML, Xen, LibXL, QEMU & ESX
> > 
> >  - Lifecycle events for all top level objects
> > 
> >     https://bugzilla.redhat.com/show_bug.cgi?id=636027
> > 
> >     * virConnectInterfaceEventRegisterAny
> >     * virConnectNetworkEventRegisterAny
> >     * virConnectNWFilterEventRegisterAny
> >     * virConnectNodeDeviceEventRegisterAny
> >     * virConnectSecretEventRegisterAny
> >     * virConnectStoragePoolEventRegisterAny
> > 
> > 
> >  - Fine grained access control
> > 
> >     https://bugzilla.redhat.com/show_bug.cgi?id=636148
> > 
> >     * Access control infrastructure
> >     * PolicyKit driver impl
> >     * Simple RBAC driver impl
> >     * SELinux driver impl            (probably not needed for 1.0)
> > 
> > 
> > Do you have suggestions for anything else that you think is very
> > important for libvirt ?
> > 
> > Regards,
> > Daniel
> 
> Maybe a set of APIs for runtime setting of some deamon knobs, e.g.
> maxClients, workerPoolSize, etc.

This is more complex than it first appears. With libvirt.so, opening
a connection to libvirtd is tied to opening a hypervisor driver. We
want to be able to control/configure the daemon independently of any
hypervisor driver. Also these controllable features may appear or
disappear over time, so we don't want to be tied into the libvirt.so
ABI/API guarantees for this.

So IMHO what we want is a libvirt-admin.so which exposes APIs for
controlling libvirtd, which takes a path to a libvirtd UNIX socket
to open a connection. Probably we even want to have a separtate UNIX
socket for this, /var/run/libvirt/libvirt-sock-admin which can have
its access controlled independantly of the main socket and default
to root:root only.

While I want to see all this, I don't think it is really a killer
feature for a 1.0 release.

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 :|