8:29 a.m.
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
11:02 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:33 a.m.
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
11:59 a.m.
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 -=|
6307
days inactive
6307
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon