On Tue, Jun 14, 2016 at 12:30:57PM +0200, Erik Skultety wrote:
It's been a while since an RFE for getting and setting specific
daemon
configuration parameters[1] during runtime landed in bugzilla. Although
there was only need for dynamic reconfiguration of number of connected
clients allowed in the original request, the plan Dan proposed was to
implement a separate libvirt administration library, specifying some
ideas regarding the functionality that the first version should support.
These of course needed a fair amount of helper functions (before any API
could be introduced), so a decision to explicitly disable creation of
the admin socket (also neither distributing the .so nor the header)
until the interface is capable to do something more than just
connecting/disconnecting, listing servers and polling for library
version has been made.
Besides the dynamic reconfiguration of the logging parameters which has
been waiting in the list (presumably needs a fresh rebase onto the
current master) due to being related and dependent on the logging level
refactor[2] (I CCed Daniel as he might have an update on this), the
Given the feedback on my patch wrt backcompat issues, I'm still undecided
about how to proceed with that patch. So I would suggest *not* rebasing
your logging series onto that patch. Instead just drop the code related
configuring log_level from your patch series, until we decide what todo
with log_level longer term.
remaining requirements on the interface have been met already. So I
was
wondering if we could manage to enable it in the upcoming release, as
well as getting it to 7.3 (thus not delaying the RFC anymore). I'd like
to hear your opinions on this matter, possibly because I might have
missed something that would cause the "official" release of the feature
to be prolonged even more.
Yep, we have APIs merged for querying which network services are enabled,
resource limits and querying about clients. I think that is more than
sufficient to justify enabling the admin API.
Probably the only thing I think we should clarify is what we intend our
long term API/ABI policy to be for libvirt-admin.so.
With libvirt-qemu.so & libvirt-lxc.so we've said they're liable to change,
but in reality have never changed them. For libvirt-admin.so it was also
the intention that it would be liable to change API, hence why it was not
part of the main libvirt.so.
I wonder if we should put up a docs pages on the website to explicitly
state what the ABI/API stability rules are for our .so libraries, as well
as virsh, and our XML formats. We've always said they're stable but AFAIR
the most we've documented is this pretty outdated page
http://libvirt.org/goals.html
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 :|