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