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.
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.
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