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