[libvirt] Continuation of Admin APIs

Wed Jul 22 11:13:07 UTC 2015

On Wed, Jul 22, 2015 at 11:02:11AM +0100, Daniel P. Berrange wrote:
>On Tue, Jun 16, 2015 at 06:03:39PM +0200, Martin Kletzander wrote:
>> So now that we have the Admin API backend merged in, the code is
>> prepared to have new APIs added in.  There are many things to be
>> added, but we should start out slowly with the most desired ones.
>> I'll try to outline what I have in my mind so the discussion can
>> sprout into existence.
>>
>> As Erik (Cc'd) expressed his interest in this, I'm just summarizing my
>> ideas here, feel free to trash them if you feel like your idea is
>> better.
>>
>> Apart from adding new APIs, we also need to split virsh to create
>> virt-admin.  I've hit a few bumps on that and Erik started looking at
>> that either, but that's outside of the scope of this email.
>>
>>
>> * What to start with
>>
>> ** Changing debugging settings
>>
>> This is something that makes sense and should be easy to do.  I
>> imagine something along the lines of virAdmSetDebug() being able to
>> setup log_level, log_filters, log_outputs (and maybe log_buffer_size).
>> The question is whether we want these to be three (or four) parameters
>> (since that number in unlikely to change) or typed parameters.  Even
>> though I like the extensibility of typed parameters, I'd probably vote
>> for the former.  Mainly because this might become syntactic sugar to
>> some heavier API (see below).  There might be flags for persisting
>> such settings, but that's highly debatable and might be also done
>> later on.
>>
>> The only situation in which we might not want this API is if there is
>> another one that is able to stream debug logs using virStream.  There
>> must be some "double-buffering" done for this since we would ran into
>> bunch of problems.
>>
>> ** Reporting connection/client information
>>
>> This is a harder one to design since there is not primary key
>> associated with each client.  We'll need to come up with some, maybe
>> combined one (based on more information, e.g. socket info, connection
>> time).  And if there's nothing better, then I guess associating a ID
>> with each new connection (be it uint64 or UUID) will have to do.
>>
>> Then we have to come up with how to represent the client data so it's
>> scalable.  We might need to resort to something else than a structure,
>> for binary extensibility.
>>
>> ** Forcibly disconnecting a client
>>
>> I haven't checked this thoroughly, but I can certainly see the problem
>> where setting client->wantClose = true might just not be enough.  If
>> all non-workers are occupied with blocking API, disconnecting clients
>> won't help with making the server accessible again.  And that leads me
>> to another one.
>>
>> ** Changing worker pool parameters
>>
>> In case the (maximum) number of workers needs to be changed, it should
>> be possible by this API.  However, there's yet again a question
>> whether this is needed if we'll have a bigger gun for all daemon
>> settings.  That's described in the next section.
>>
>>
>> * Future ideas (for consideration)
>>
>> ** Changing any settings for the libvirt daemon.
>>
>> I had an idea that we should have a "universal" API for changing any
>> settings that comes from config files.  The API that would implement
>> this would have a string parameter (or list of strings) that would say
>> what setting(s) to change, similarly to augtool.  So let's say instead
>> of:
>>
>> $ augtool -s set /files/etc/libvirt/libvirtd.conf/max_workers 10
>>
>> one would call:
>>
>> virAdmSetConfig("libvirtd.conf/max_workers", "10", ...);
>>
>> Good thing about this is that it is highly scalable (even to
>> qemu.conf).  Bad thing is that we need to be able to say whether there
>> is a setting that we don't yet support (return error_unsupported) and
>> also we'd need to rework the configuration module to be able to do
>> such thing and have a function to call for each change.
>>
>> Having this would render changing max_workers, log_level etc. obsolete
>> (although I feel like changing debug parameters still deserves its own
>> API function).
>>
>> ** Reloading the server's TLS certificates?
>>
>> This was requested by Lee (Cc'd) in a reply to one of the PoC series.
>> It is something that I feel like we really want as well, but I haven't
>> yet put much thought into it.
>>
>>
>> That's all from me now.  I won't have much access to my mail in couple
>> of following days, so I'll be slower to respond, even slower than my
>> usual slow.
>
>The other day I was thinking about the admin API and had one point
>that I think we've not actively discussed before.
>
>We've always been thinking in terms of libvirtd, but we already have
>another virtlockd daemon. I'm also working on a virtlogd daemon to
>handle logging better, and we might also get a virtshmemd daemon to
>deal with ivshmem devices in QEMU.
>
>As such, I think we need to make sure that the admin API works
>across all of these daemons in the same way. eg, the libvirt-admin.so
>client open API should be able to accept different URIs to tell it
>which daemon to connect to, and the server side code should be
>something we turn on it all our RPC daemons.
>

Definitely.  We can change the URI accepted and incorporate a "daemon
name" into it.  It can already handle arbitrary socket paths, but
nobody wants to specify the whole path when we can have sensible
defaults.

>For the suggested features you mention above, I think that should
>not be any real difficulty, since they are all things related to
>global features (logging, config) or the RPC server codebase.
>
>If we did ever want to add some admin features that are specific
>to libvirtd and not applicable to virtlockd/virtlogd/etc, then
>we might want to be a bit more careful. It might be that we need
>to actively distinguish general administrative APIs from daemon
>specific administrative APIs, by having separate RPC programs
>and client libraries if we get into that area.
>
>An example would be, the virtlockd daemon. Consider if we want
>to add an administrative API to allow us to break locks. That
>would obviously not be applicable for libvirt-admin.so, so we
>might in that case need a libvirt-admin-lockd.so for that
>scenario. Likewise if there's something inherantly specific
>to libvirtd.
>

Exactly, similarly as we handle arbitrary qemu-agent commands in
libvirt-qemu.so.

But that leads me to another idea.  What if we take the whole part
where the admin interface is setting up in libvirtd and abstract it in
a way that libvirt will just have to supply 2 things during
virNetDaemon createion.  And that would be a) socket path and b)
possible additional virNetServiceServers.  For example to
virNetDaemonEnableAdmin() function.  It would be nice syntax-sugar,
although I see the problem with configuration being in libvirtd.conf
and being parsed by the daemon itself.  Well, it was just an idea.

>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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150722/2c13305e/attachment-0001.sig>