On 14.06.2016 12:38, Daniel P. Berrange wrote: > 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. Yep, I'm for 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 think that the other reason was security, we wanted admin API to be available on to root and thus had to come up with a separate library. Whatever. That's just cosmetics. For the real issue - we can say that APIs are still not written in stone and if future proof us wrong, we will change them. We did our best now, but since nobody has been trying them in production, we just don't know yet. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list