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