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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list