Re: [libvirt] ANNOUNCE: Plans for the next release
On Wed, May 16, 2018 at 01:38:06PM +0200, Pavel Hrdina wrote: > On Wed, May 16, 2018 at 12:09:15PM +0100, Daniel P. Berrangé wrote: > > On Mon, May 14, 2018 at 05:15:59PM +0200, Pavel Hrdina wrote: > > > Hi, > > > > > > I would like to make the next libvirt-dbus release with stable APIs, > > > there is a lot of them already implemented and other projects can start > > > adapting to use libvirt-dbus. > > > > > > The release version would be 1.0.0 and currently libvirt-dbus will > > > cover APIs up to libvirt-3.0.0 as a start point because that libvirt > > > version is available in all downstream distributions currently > > > supported by libvirt. > > > > > > So I would like to ask everyone to look at the APIs to check whether it > > > make sense and whether something is missing or could be excluded. > > > > I'd suggest writing a test that parses libvirt-api.xml and validates that > > your binary (or source code) contains a reference to each API, so that you > > know you have full coverage, and also so that CI builds when when new APIs > > are added to libvirt alerting you to close the gap. Just blacklist the > > APIs you don't want to expose. There's examples of such a test in the > > python, perl and go binding repos. > > Yes, definitely good suggestion. Actually I have it in my mind to do > it, but I was waiting until we implement all APIs. But since you've > mentioned it I've realized that it could be useful to do it now to in > order to track what APIs are left to implement so we don't miss any. Yeah, when I was writing the Go bindings, I created the test first, and blacklisted all missing APIs. Then gradually removed APIs from the blacklist as I implemented them, until I got just the bits I didn't want to expose. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ANNOUNCE: Plans for the next release
On Wed, May 16, 2018 at 12:09:15PM +0100, Daniel P. Berrangé wrote: > On Mon, May 14, 2018 at 05:15:59PM +0200, Pavel Hrdina wrote: > > Hi, > > > > I would like to make the next libvirt-dbus release with stable APIs, > > there is a lot of them already implemented and other projects can start > > adapting to use libvirt-dbus. > > > > The release version would be 1.0.0 and currently libvirt-dbus will > > cover APIs up to libvirt-3.0.0 as a start point because that libvirt > > version is available in all downstream distributions currently > > supported by libvirt. > > > > So I would like to ask everyone to look at the APIs to check whether it > > make sense and whether something is missing or could be excluded. > > I'd suggest writing a test that parses libvirt-api.xml and validates that > your binary (or source code) contains a reference to each API, so that you > know you have full coverage, and also so that CI builds when when new APIs > are added to libvirt alerting you to close the gap. Just blacklist the > APIs you don't want to expose. There's examples of such a test in the > python, perl and go binding repos. Yes, definitely good suggestion. Actually I have it in my mind to do it, but I was waiting until we implement all APIs. But since you've mentioned it I've realized that it could be useful to do it now to in order to track what APIs are left to implement so we don't miss any. I'll look into it later, I guess there is no rush to do it before the release. Thanks, Pavel signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ANNOUNCE: Plans for the next release
On Mon, May 14, 2018 at 05:15:59PM +0200, Pavel Hrdina wrote: > Hi, > > I would like to make the next libvirt-dbus release with stable APIs, > there is a lot of them already implemented and other projects can start > adapting to use libvirt-dbus. > > The release version would be 1.0.0 and currently libvirt-dbus will > cover APIs up to libvirt-3.0.0 as a start point because that libvirt > version is available in all downstream distributions currently > supported by libvirt. > > So I would like to ask everyone to look at the APIs to check whether it > make sense and whether something is missing or could be excluded. I'd suggest writing a test that parses libvirt-api.xml and validates that your binary (or source code) contains a reference to each API, so that you know you have full coverage, and also so that CI builds when when new APIs are added to libvirt alerting you to close the gap. Just blacklist the APIs you don't want to expose. There's examples of such a test in the python, perl and go binding repos. > The idea of libvirt-dbus is not to export every API if there is a better > API to do the job, so for example: > > - all APIs that have both versions with and without flags we will > export only the one with flags. > > - some of the Stats APIs can be omitted since the same values are > also exported in the GetStats (virDomainListGetStats) > > I would like to make the release this week so any help or suggestion is > welcome. The API definition is in the data/org.libvirt.*.xml files. > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] ANNOUNCE: Plans for the next release
Hi, I would like to make the next libvirt-dbus release with stable APIs, there is a lot of them already implemented and other projects can start adapting to use libvirt-dbus. The release version would be 1.0.0 and currently libvirt-dbus will cover APIs up to libvirt-3.0.0 as a start point because that libvirt version is available in all downstream distributions currently supported by libvirt. So I would like to ask everyone to look at the APIs to check whether it make sense and whether something is missing or could be excluded. The idea of libvirt-dbus is not to export every API if there is a better API to do the job, so for example: - all APIs that have both versions with and without flags we will export only the one with flags. - some of the Stats APIs can be omitted since the same values are also exported in the GetStats (virDomainListGetStats) I would like to make the release this week so any help or suggestion is welcome. The API definition is in the data/org.libvirt.*.xml files. Thanks and regards Pavel signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
