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
>> 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,
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
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.