search

rgbkrk / libvirt-go

[DEPRECATED] Go bindings for libvirt
https://github.com/libvirt/libvirt-go
MIT License
166 stars 50 forks source link

libvirt's official Go bindings #127

Closed vincentbernat closed 7 years ago

vincentbernat commented 7 years ago

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?

rgbkrk commented 7 years ago

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

purpleidea commented 7 years ago

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.

purpleidea commented 7 years ago

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.

feiskyer commented 7 years ago

So do we need to deprecate this project and prefer upstream's one? It seems the upstream one is based on this repo.

rgbkrk commented 7 years ago

/cc @berrange

rmohr commented 7 years ago

Was very surprised by that too, but deprecating this absolutely makes sense and getting all the features is very nice.

rmohr commented 7 years ago

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.

berrange commented 7 years ago

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.

berrange commented 7 years ago

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

purpleidea commented 7 years ago

We've switched to the new upstream. https://github.com/purpleidea/mgmt/issues/104

Are folks interested in officially deprecating this project and pointing the README to the libvirt upstream?

vincentbernat commented 7 years ago

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.

purpleidea commented 7 years ago

@vincentbernat RE: https://github.com/rgbkrk/libvirt-go/commit/b9c1810fcd258c294038c0cd2e749bf8282f9036 s/those/these/ ?

What's your project?

vincentbernat commented 7 years ago

Unfortunately, not open source yet. It's some kind of SDN controller for cloud.

purpleidea commented 7 years ago

On Thu, Jan 5, 2017 at 7:09 AM, Vincent Bernat notifications@github.com wrote:

Unfortunately, not open source yet. It's some kind of SDN controller for cloud.

Well if you'd like some automation help around it, come join us on https://github.com/purpleidea/mgmt/ </cheap plug>

mraygalaxy commented 7 years ago

Woo hoo.

purpleidea commented 7 years ago

Looks like we can close this.