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