[Libvir] Stability of virsh / libvirt interfaces
This has probably been discussed before so apologies. What is the current status of the interfaces, especially libvirt and virsh? Are they guaranteed to be stable? Does this apply to every new interface as soon as a release is done? (I ask after noticing that virsh schedinfo can be used to *set* parameters!) thanks john
On Fri, Aug 17, 2007 at 02:29:51PM +0100, John Levon wrote:
This has probably been discussed before so apologies.
What is the current status of the interfaces, especially libvirt and virsh? Are they guaranteed to be stable? Does this apply to every new interface as soon as a release is done?
I will apply the same strategy as for libxml2/xmllint as this worked well for quite a few years: - once an API is published in a release version, I will make all effort possible to never break an application using it, be it at the API or ABI level. The only exception to that rule would be if we can conclude positively that no app can use that API. For example we removed an enum from the API a month ago since there was no entry point where it could ever be used. Of course an error is possible but really the policy is clear - Adding APIs is fine as the project evolves is normal process, but based on my libxml2 experience I will try also very hard to not push too early so we don't have to pile up the various version (preceding from previous point as we can't remove once released) Now for virsh, since it's an application it's a bit less crucial, but I will definitely try to follow the same policy.
(I ask after noticing that virsh schedinfo can be used to *set* parameters!)
It's kind of an API extensions, i.e. adding set to an existing get as long as I don't see how this could break, adding stuff should not be a problem. What's the problem, if you're used only to read you pass only 2 arguments. To set you need more argument, somehow it's a new API (from a textual API perspective). Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, Aug 17, 2007 at 12:02:11PM -0400, Daniel Veillard wrote:
I will apply the same strategy as for libxml2/xmllint as this worked well for quite a few years:
[snip] OK, that sounds fine, I just wanted a clear statement of where the project's at.
(I ask after noticing that virsh schedinfo can be used to *set* parameters!)
It's kind of an API extensions, i.e. adding set to an existing get as long as I don't see how this could break, adding stuff should not be a problem. What's the problem, if you're used only to read you pass only 2 arguments. To set you need more argument, somehow it's a new API (from a textual API perspective).
I really meant that it's very odd that something called 'info' can set stuff, and it would have been nice to fix that, though of course we can't now. thanks, john
On Fri, Aug 17, 2007 at 05:33:57PM +0100, John Levon wrote:
On Fri, Aug 17, 2007 at 12:02:11PM -0400, Daniel Veillard wrote:
I will apply the same strategy as for libxml2/xmllint as this worked well for quite a few years:
[snip]
OK, that sounds fine, I just wanted a clear statement of where the project's at.
(I ask after noticing that virsh schedinfo can be used to *set* parameters!)
It's kind of an API extensions, i.e. adding set to an existing get as long as I don't see how this could break, adding stuff should not be a problem. What's the problem, if you're used only to read you pass only 2 arguments. To set you need more argument, somehow it's a new API (from a textual API perspective).
I really meant that it's very odd that something called 'info' can set stuff, and it would have been nice to fix that, though of course we can't now.
Yeah, I didn't realize it could be used to set parameters either, and to be honest I think its syntax for doing so sucks since it is stupidly Xen specific in parameters it accepts. I think we should deprecate use of schedinfo for setting params, and provide an alternate setdomsched command, with a more flexible syntax. Since we need to specify type for various params, a syntax using --int NAME=VAL with similar for --uint, --long, --ulong, --double, --char virsh setdomsched --int weight=1 --int cap=24 myguest Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon