[libvirt] RFC: TODO list for a 1.0 release
Daniel P. Berrange
berrange at redhat.com
Mon May 21 12:21:11 UTC 2012
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 :|
More information about the libvir-list
mailing list