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.
Have a nice day,
Martin
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list