libvirt's official Go bindings
vincentbernat opened this issue · 16 comments
Hey!
I have found this in my RSS reader: https://www.berrange.com/posts/2016/12/15/announce-new-libvirt-project-go-language-bindings/
It comes with a bit of surprise as I don't think we got any contact towards that. However, I see this is as good news as the binding will now be maintained upstream and stay up-to-date without any effort on our part. The blog post contains indications to migrate to the new one. However, it is not complete yet (no events).
Should we say our users to switch? Add a link in README?
Neat!
Daniel did email back and forth with me and I just noticed that I had left a response in draft. D'oh!
As I think I've said before, since I'm no longer using this library and largely only here in name-only, I more than welcome a successor to this project.
Another note, from meeting with @taotetek - Digital Ocean made their own libvirt bindings that they released as open source and use internally: https://github.com/digitalocean/go-libvirt
I'd vote to switch to this. Full disclosure, I work for Red Hat, although I didn't know this happened until I saw this post.
RE:
Another note, from meeting with @taotetek - Digital Ocean made their own libvirt bindings that they released as open source and use internally: https://github.com/digitalocean/go-libvirt
I thought that was really awesome as well, however after talking with the libvirt upstream, they strongly recommended against this approach, as it's subject to change, breakage, etc, as that RPC interface they use is non-public and not stable.
So do we need to deprecate this project and prefer upstream's one? It seems the upstream one is based on this repo.
Was very surprised by that too, but deprecating this absolutely makes sense and getting all the features is very nice.
I thought that was really awesome as well, however after talking with the libvirt upstream, they strongly recommended against this approach, as it's subject to change, breakage, etc, as that RPC interface they use is non-public and not stable.
Still it is a very interesting approach and allows some use-cases which are currently not possible because of the c-bindings opacity.
Sorry for the surprise - I had emailed Kyle only a few times assuming he was still primarily driving the project, not realizing other people were doing most of the work these days. I totally appreciate all the work everyone has put into this library so far - it has been very valuable.
FYI, the events APIs will most likely be implemented by end of today. The two big TODO items I have are writing integration tests to cover the new APIs since I've only added a few tests so far, and adding API documentation for every API. So if anyone is interested in helping out, I'd still welcome contributions.
The other thing I'm looking todo is create a second independant library libvirt-go-xml that maps the libvirt XML schemas into Go structs, using the encoding/xml package, since every app using libvirt from Go will have this same need.
@rmohr I'm curious which use cases you think they deal with, and whether we can better address them in the native library binding ? Being version independent as opposed to requiring build tags was a big plus, but with the way we can do conditional compilation against any libvirt version, that benefit is reduced. Unless perhaps running on a remote platform which doesn't happen to have libvirt installed at all, but the digital ocean bindings don't support any authentication or encryption options though, making them useless for remote access right now.
FYI, i pushed the very basic initial code of an API for libvirt XML mapping to encoding/xml http://libvirt.org/git/?p=libvirt-go-xml.git;a=summary, also visible at https://github.com/libvirt/libvirt-go-xml / https://godoc.org/github.com/libvirt/libvirt-go-xml
We've switched to the new upstream. purpleidea/mgmt#104
Are folks interested in officially deprecating this project and pointing the README to the libvirt upstream?
I thought we already added the appropriate mention in README. We have also switched to the new bindings in our project, without much difficulty. I'll do a PR shortly.
@vincentbernat RE: b9c1810 s/those/these/ ?
What's your project?
Unfortunately, not open source yet. It's some kind of SDN controller for cloud.
Woo hoo.
Looks like we can close this.