Re: Enabling libvirt admin API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]