Re: [libvirt] Continuation of Admin APIs

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.