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