[libvirt] RFC: TODO list for a 1.0 release

[Daniel P. Berrange]

On Mon, May 21, 2012 at 10:27:38AM +0100, 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)

Oh I should say, I'm not neccessarily convinced that we need any of the
fine grained access control stuff for a 1.0 release. While I think the
functionality will be useful for some scenarios, for a great many users
of libvirt it is simply not relevant. I included it in the list because
DV mentioned it as something he thought was worthwhile.

The API/events additions by contrast would be useful to pretty much
every single user of the libvirt API, and solve a number of clear
flaws in our existing APIs.

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