On 07.06.2017 10:55, Martin Pitt wrote: > Stef Walter [2017-06-07 10:47 +0200]: >> On 07.06.2017 07:49, Martin Pitt wrote: >>> C/GI interfaces also don't map well to D-Bus, i. e. it's not practical to >>> autogenerate a D-Bus interface for a given GI API. This still works for the >>> most simple methods that only accept primitive data types and strings, but >>> as >>> soon as you pass any structs, pointers, function pointers etc. around this >>> can't be exposed though D-Bus any more without further interpretation on the >>> server side. >> >> Perhaps not an runtime. But it seems like such a thing could be done at >> compile time for the libvirt C API. The libvirt folks do it for their >> python bindings, using code generation. >> >> The libvirt Python API behaves a lot like the C API. It's very flat and >> not very "pythonic". Which is actually a nice target for us. We could do >> something similar with a simple "flat" DBus wrapper of the API ... using >> code generation. > > Sure, one can always write code to map the libvirt API into a D-Bus API (in C, > Python, or JavaScript with GJS, but I suppose for this use case Python might > be > the best choice). My point was just that this would require to create, > package, and ship new code on the target machines, which is a very high > barrier > for stable OS releases (particularly RHEL/CentOS, but it's not easy at all for > e. g. Debian or Ubuntu either). > > Peter and I discussed if we could get away somehow with the existing code/APIs > on stable releases. E. g. a hackish, but maybe workable first step might be to > only use the python-libvirt API for subscribing to desired notifications and > trigger the Cockpit VM module through it, but continue to handle all the > actions through virsh. This subscription/notification code will hopefully be > small enough that it can be sent "through the wire" (cockpit channel) and > executed ad-hoc, without having to actually distribute it on the remote side.
That's a decent idea. Worth trying out. In many ways virsh is a remoteable command-line API. This would help us get started given the current non-remotable status quo. The fact that libvirt is all about XML also helps here ... it means we do less screen-scraping. But I suppose the fact that virsh can execute multiple commands doesn't really buy us very much ... because it goes too far down the road of screen-scraping. All in all worth trying out. This lets us focus on building the actual interface. And if a remotable API for libvirt shows up later, we could swap over to it without too much effort. Stef
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org
