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