[libvirt] RFC: TODO list for a 1.0 release
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 -- |: 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 :|
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. Michal
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 :|
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 :|
On 05/21/2012 05:27 AM, 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.
WRT developing apps, improved capabilities reporting about what a libvirt driver actually supports. So things like - API calls (qemu supports Migrate*, UML doesn't. also connecting to a libvirtd 1.0 isn't going to support all the APIs of my 1.3 client) - API flags (qemu supports VIR_DOMAIN_START_PAUSED, UML doesn't) Reporting a lot of that should be pretty straight forward. The more daunting bit is: - XML elements (qemu supports <sound>, UML doesn't) This can be different per domain, for example in qemu this could depend on a domain's emulator, domain type, machine type, arch, etc. Indeed individual API support could come down to domain config as well, think hotplug. So depending on how detailed we want to get this could be pretty hairy. Also, adding *WithFlags APIs for any current API which doesn't take flags, even if there isn't a use yet. - Cole
On Mon, May 21, 2012 at 10:27:38 +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
I think 1.0 could be the right time to start using deprecating older APIs for which we have a better equivalent (e.g., all the old List APIs would become deprecated in 1.0). By deprecating I do _not_ mean that we should start removing them. The APIs would remain in the library for backward compatibility but they would be clearly marked as deprecated (with a link to the replacement APIs) in the API documentation. Such APIs would not get any new enhancements but bugs would still be fixed if possible within the deprecated APIs design. And we should make gcc emit compile-time warning when an application tries to use them. This would be either turned on by default with an option to turn it off or the other way around. Jirka
On 05/21/2012 05:27 AM, 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.
- Lifecycle events for all top level objects
About lifecycle events - your recent patches adding a few new hooks were very useful. I can see at least one other place that I think warrants a hook (and an event) - Stefan's DHCP snooping patch will allow libvirt to learn the IP address of a guest, which could be important to have in some sort of external action related to the guest. It would be good if there was a hook called (and event generated) any time this new code detected a DHCP lease being acquired or expiring (more generically, I guess any time a libvirt-detectable change in a guest's network config/status was encountered).
https://bugzilla.redhat.com/show_bug.cgi?id=636027
* virConnectInterfaceEventRegisterAny
Interesting. Somehow I'd never seen this BZ before. For the case of virInterface, I have plans to add some sort of event API to netcf that will notify registrants when the host interface config changes, and could be used to feed interface events (this new netcf API is necessary to write a working NetworkManager plugin using netcf).
Do you have suggestions for anything else that you think is very important for libvirt ?
In order for gnome boxes (and similar management applications that use qemu:///session) to give guests reasonable network devices, we need to make all of the qemu:///system network types (including defined networks, macvtap, openvswitch bridges) available to qemu:///session (after getting past policykit). Upstream qemu now has a setuid binary to do this for basic host bridges, but this is only a small subset of what libvirt supports, and uses file-based ACLs rather than policykit to control who is allowed to create the network devices. Oh, and also, it requires that qemu be installed (I guess I forgot to mention that this should work for lxc too, implying that qemu may missing from the host).
Il 05/06/2012 18:53, Laine Stump ha scritto:
Upstream qemu now has a setuid binary to do this for basic host bridges, but this is only a small subset of what libvirt supports, and uses file-based ACLs rather than policykit to control who is allowed to create the network devices. Oh, and also, it requires that qemu be installed (I guess I forgot to mention that this should work for lxc too, implying that qemu may missing from the host).
FWIW, patches or simply guidance on how to add PK support would be very appreciated. It's just that nobody in the QEMU community has even thought of doing that, but now that you mention it, it would be a very nice addition. Paolo
Il 21/05/2012 11:27, Daniel P. Berrange ha scritto:
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)
Persistent nodedevs (i.e. nodedev-{define,start,undefine}). Not a major feature, but the current nodedev API is a bit unorthogonal and they are my preferred solution for transparent NPIV migration. Paolo
participants (6)
-
Cole Robinson -
Daniel P. Berrange -
Jiri Denemark -
Laine Stump -
Michal Privoznik -
Paolo Bonzini