[libvirt] RFC: Drop unmaintained hv drivers? (phyp, xenapi, hyperv)
Hi all, There's a few old hypervisor drivers in the tree that haven't been actively maintained for a long time. I'm curious if anyone knows of these drivers being actively used. If not I think we should consider dropping them src/phyp/ : for power VM hypervisor. Added in July 2009. The last commit that looks like it wasn't either internal API conversion, or caught by code analysis, is: commit 41461ff7f7d6ee6679aae2a8004e305c5830c9e8 Author: Eduardo Otubo <otubo@linux.vnet.ibm.com> Date: Tue Apr 19 12:34:08 2011 -0300 PHYP: Adding reboot domain function Adding reboot <domain> function for pHyp driver. Nearly 5 years ago. Eduardo is the primary driver author too (CCd at his email from github). Searching the upstream bug tracker for all bugs with 'phyp', the only one that's actually about the phyp driver is a report from 2 years ago that it crashes trying to open a connection: https://bugzilla.redhat.com/show_bug.cgi?id=1093094 src/xenapi/: Connecting to a xen api server. Added in March 2010. Largely appears to be a code drop, the original author/committer has never had another commit. The last xenapi specific commit seems to be: commit 484460ec4678a264c5e7355495c2f0da72cb42bd Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Thu Jul 21 15:16:11 2011 +0200 xenapi: Improve error reporting in xenapiOpen once again Nearly 5 years ago. The only upstream bug that was filed about xenapi is: https://bugzilla.redhat.com/show_bug.cgi?id=711372 Which was about a connection failure that was eventually fixed upstream, and dovetailed into the above referenced commit. Current xen guys, you know of anyone using this? src/hyperv/: Added in July 2011. This was largely a code drop as well; committed and patched a few times by Matthias but it was a university project by someone else. Last hyperv targeted patch was: commit 9e9ea3ead9825bd1dc2c17cea4abc8c4165591d0 Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Sun Sep 9 17:39:40 2012 +0200 hyperv: Fix and improve hypervListAllDomains The driver is fairly minimal as well: it can only list existing VMs and perform lifecycle operations. It can't create new VMs, and doesn't list VM device config AFAICT. Also, in general, I've never heard about anyone _actually_ using any of those drivers in the wild. There's reports here and there but it mostly sounds like people trying them out. Just an anecdote so take it with a grain of salt - Cole
2016-04-15 21:54 GMT+02:00 Cole Robinson <crobinso@redhat.com>:
Hi all,
There's a few old hypervisor drivers in the tree that haven't been actively maintained for a long time. I'm curious if anyone knows of these drivers being actively used. If not I think we should consider dropping them
src/phyp/ : for power VM hypervisor. Added in July 2009. The last commit that looks like it wasn't either internal API conversion, or caught by code analysis, is:
commit 41461ff7f7d6ee6679aae2a8004e305c5830c9e8 Author: Eduardo Otubo <otubo@linux.vnet.ibm.com> Date: Tue Apr 19 12:34:08 2011 -0300
PHYP: Adding reboot domain function
Adding reboot <domain> function for pHyp driver.
Nearly 5 years ago. Eduardo is the primary driver author too (CCd at his email from github).
Searching the upstream bug tracker for all bugs with 'phyp', the only one that's actually about the phyp driver is a report from 2 years ago that it crashes trying to open a connection:
I developed this driver as per internal IBM project's request. I left IBM in 2014 and I really don't know if anyone uses this feature (internally or not) anymore. I'll try to check it out and get back to this thread as soon as I have some info. Regards,
src/xenapi/: Connecting to a xen api server. Added in March 2010. Largely appears to be a code drop, the original author/committer has never had another commit. The last xenapi specific commit seems to be:
commit 484460ec4678a264c5e7355495c2f0da72cb42bd Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Thu Jul 21 15:16:11 2011 +0200
xenapi: Improve error reporting in xenapiOpen once again
Nearly 5 years ago. The only upstream bug that was filed about xenapi is:
https://bugzilla.redhat.com/show_bug.cgi?id=711372
Which was about a connection failure that was eventually fixed upstream, and dovetailed into the above referenced commit. Current xen guys, you know of anyone using this?
src/hyperv/: Added in July 2011. This was largely a code drop as well; committed and patched a few times by Matthias but it was a university project by someone else. Last hyperv targeted patch was:
commit 9e9ea3ead9825bd1dc2c17cea4abc8c4165591d0 Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Sun Sep 9 17:39:40 2012 +0200
hyperv: Fix and improve hypervListAllDomains
The driver is fairly minimal as well: it can only list existing VMs and perform lifecycle operations. It can't create new VMs, and doesn't list VM device config AFAICT.
Also, in general, I've never heard about anyone _actually_ using any of those drivers in the wild. There's reports here and there but it mostly sounds like people trying them out. Just an anecdote so take it with a grain of salt
- Cole
-- otubo
On Fri, Apr 15, 2016 at 03:54:00PM -0400, Cole Robinson wrote:
Hi all,
There's a few old hypervisor drivers in the tree that haven't been actively maintained for a long time. I'm curious if anyone knows of these drivers being actively used. If not I think we should consider dropping them
src/phyp/ : for power VM hypervisor. Added in July 2009. The last commit that looks like it wasn't either internal API conversion, or caught by code analysis, is:
commit 41461ff7f7d6ee6679aae2a8004e305c5830c9e8 Author: Eduardo Otubo <otubo@linux.vnet.ibm.com> Date: Tue Apr 19 12:34:08 2011 -0300
PHYP: Adding reboot domain function
Adding reboot <domain> function for pHyp driver.
Nearly 5 years ago. Eduardo is the primary driver author too (CCd at his email from github).
Searching the upstream bug tracker for all bugs with 'phyp', the only one that's actually about the phyp driver is a report from 2 years ago that it crashes trying to open a connection:
The phyp driver would have a fairly niche end user audience, so it would not be entirely surprising to not hear much about it.
src/xenapi/: Connecting to a xen api server. Added in March 2010. Largely appears to be a code drop, the original author/committer has never had another commit. The last xenapi specific commit seems to be:
commit 484460ec4678a264c5e7355495c2f0da72cb42bd Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Thu Jul 21 15:16:11 2011 +0200
xenapi: Improve error reporting in xenapiOpen once again
Nearly 5 years ago. The only upstream bug that was filed about xenapi is:
https://bugzilla.redhat.com/show_bug.cgi?id=711372
Which was about a connection failure that was eventually fixed upstream, and dovetailed into the above referenced commit. Current xen guys, you know of anyone using this?
The XenAPI driver was never "finished" as IIRC the person who started work on it, left XenSource before he was able to make it functional enough to be useful. The XenAPI was targetting the closed source Xen products, as opposed to the open source platform, which is now libxl based. I did vaguely remember talk of the Xen products eventualy moving over to be libxl based instead of XenAPi, but I don't know if that's actually accurate or not.
src/hyperv/: Added in July 2011. This was largely a code drop as well; committed and patched a few times by Matthias but it was a university project by someone else. Last hyperv targeted patch was:
commit 9e9ea3ead9825bd1dc2c17cea4abc8c4165591d0 Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Sun Sep 9 17:39:40 2012 +0200
hyperv: Fix and improve hypervListAllDomains
The driver is fairly minimal as well: it can only list existing VMs and perform lifecycle operations. It can't create new VMs, and doesn't list VM device config AFAICT.
This is a fairly similar level of functionality to the XenAPI driver, but I'm pretty loathe for us to loose even the limited hyperv support, as it is very much an active product that's not going away. In general I'm not really in favour of dropping virt drivers for hypervisor platforms that still exist and have potential users, even if we don't hear much about them. I don't think any of these drivers is really giving us a significant maintenance headache to justify deletion. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 04/18/2016 05:21 AM, Daniel P. Berrange wrote:
On Fri, Apr 15, 2016 at 03:54:00PM -0400, Cole Robinson wrote:
Hi all,
There's a few old hypervisor drivers in the tree that haven't been actively maintained for a long time. I'm curious if anyone knows of these drivers being actively used. If not I think we should consider dropping them
src/phyp/ : for power VM hypervisor. Added in July 2009. The last commit that looks like it wasn't either internal API conversion, or caught by code analysis, is:
commit 41461ff7f7d6ee6679aae2a8004e305c5830c9e8 Author: Eduardo Otubo <otubo@linux.vnet.ibm.com> Date: Tue Apr 19 12:34:08 2011 -0300
PHYP: Adding reboot domain function
Adding reboot <domain> function for pHyp driver.
Nearly 5 years ago. Eduardo is the primary driver author too (CCd at his email from github).
Searching the upstream bug tracker for all bugs with 'phyp', the only one that's actually about the phyp driver is a report from 2 years ago that it crashes trying to open a connection:
The phyp driver would have a fairly niche end user audience, so it would not be entirely surprising to not hear much about it.
src/xenapi/: Connecting to a xen api server. Added in March 2010. Largely appears to be a code drop, the original author/committer has never had another commit. The last xenapi specific commit seems to be:
commit 484460ec4678a264c5e7355495c2f0da72cb42bd Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Thu Jul 21 15:16:11 2011 +0200
xenapi: Improve error reporting in xenapiOpen once again
Nearly 5 years ago. The only upstream bug that was filed about xenapi is:
https://bugzilla.redhat.com/show_bug.cgi?id=711372
Which was about a connection failure that was eventually fixed upstream, and dovetailed into the above referenced commit. Current xen guys, you know of anyone using this?
The XenAPI driver was never "finished" as IIRC the person who started work on it, left XenSource before he was able to make it functional enough to be useful. The XenAPI was targetting the closed source Xen products, as opposed to the open source platform, which is now libxl based. I did vaguely remember talk of the Xen products eventualy moving over to be libxl based instead of XenAPi, but I don't know if that's actually accurate or not.
src/hyperv/: Added in July 2011. This was largely a code drop as well; committed and patched a few times by Matthias but it was a university project by someone else. Last hyperv targeted patch was:
commit 9e9ea3ead9825bd1dc2c17cea4abc8c4165591d0 Author: Matthias Bolte <matthias.bolte@googlemail.com> Date: Sun Sep 9 17:39:40 2012 +0200
hyperv: Fix and improve hypervListAllDomains
The driver is fairly minimal as well: it can only list existing VMs and perform lifecycle operations. It can't create new VMs, and doesn't list VM device config AFAICT.
This is a fairly similar level of functionality to the XenAPI driver, but I'm pretty loathe for us to loose even the limited hyperv support, as it is very much an active product that's not going away.
In general I'm not really in favour of dropping virt drivers for hypervisor platforms that still exist and have potential users, even if we don't hear much about them. I don't think any of these drivers is really giving us a significant maintenance headache to justify deletion.
It's just kind of a weird situation. We advertise support for these platforms, but if someone tries them and finds them lacking and reports an issue here, the only response they are going to get is 'no one has worked on it for years, no one here has a setup to test, sorry we cannot help you'. That's if they get a response at all. Seems bizarre to me... - Cole
On Mon, Apr 18, 2016 at 08:54:15AM -0400, Cole Robinson wrote:
On 04/18/2016 05:21 AM, Daniel P. Berrange wrote:
On Fri, Apr 15, 2016 at 03:54:00PM -0400, Cole Robinson wrote:
In general I'm not really in favour of dropping virt drivers for hypervisor platforms that still exist and have potential users, even if we don't hear much about them. I don't think any of these drivers is really giving us a significant maintenance headache to justify deletion.
It's just kind of a weird situation. We advertise support for these platforms, but if someone tries them and finds them lacking and reports an issue here, the only response they are going to get is 'no one has worked on it for years, no one here has a setup to test, sorry we cannot help you'. That's if they get a response at all. Seems bizarre to me...
This is implying that because we don't have an active maintainer who will answer bug reports, then the driver is entirely useless to everybody. I find that really dubious, because it ignores the possibility that people are happily using the other parts of it that actually do work. Sure it would be nice if we have active maintainers, but I don't think the lack of an active maintainer means the driver is useless to all users. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 04/18/2016 08:58 AM, Daniel P. Berrange wrote:
On Mon, Apr 18, 2016 at 08:54:15AM -0400, Cole Robinson wrote:
On 04/18/2016 05:21 AM, Daniel P. Berrange wrote:
On Fri, Apr 15, 2016 at 03:54:00PM -0400, Cole Robinson wrote:
In general I'm not really in favour of dropping virt drivers for hypervisor platforms that still exist and have potential users, even if we don't hear much about them. I don't think any of these drivers is really giving us a significant maintenance headache to justify deletion.
It's just kind of a weird situation. We advertise support for these platforms, but if someone tries them and finds them lacking and reports an issue here, the only response they are going to get is 'no one has worked on it for years, no one here has a setup to test, sorry we cannot help you'. That's if they get a response at all. Seems bizarre to me...
This is implying that because we don't have an active maintainer who will answer bug reports, then the driver is entirely useless to everybody. I find that really dubious, because it ignores the possibility that people are happily using the other parts of it that actually do work. Sure it would be nice if we have active maintainers, but I don't think the lack of an active maintainer means the driver is useless to all users.
My paragraph didn't fully describe all the assumptions; Those three drivers may have zero active users in the wild. Certainly there is no obvious evidence to the contrary. The most damning bit seems to be that there hasn't been a single targeted bug fix for those drivers in an average of 4 years; if someone was actively using those drivers I'm pretty sure we would have received a drive by patch at some point Maybe someone will chime in to prove me wrong, but what if the situation is that there's no active maintainer, and no active users? Then it truly _is_ serving no purpose, and IMO even advertising it is actively harmful since it may lead users down a dead end path Removing a driver doesn't need to be the end either... if someone motivated shows up they can always revive the old code ...now that I do some more targeted searches looking for patches, looks like someone from bull.net did try to massively expand the hyperv driver a few years back, but it was an awkward code dump: https://www.redhat.com/archives/libvir-list/2014-October/msg00257.html
On Mon, Apr 18, 2016 at 09:11:24AM -0400, Cole Robinson wrote:
Maybe someone will chime in to prove me wrong, but what if the situation is that there's no active maintainer, and no active users? Then it truly _is_ serving no purpose, and IMO even advertising it is actively harmful since it may lead users down a dead end path
Removing a driver doesn't need to be the end either... if someone motivated shows up they can always revive the old code
If the code is removed, it will no longer be kept up to date with internal libvirt APIs and concepts and latest compiler warning workarounds, so the work of getting it up to date would be on this motivated person. That could make the motivation disappear rather quickly :) Jan
...now that I do some more targeted searches looking for patches, looks like someone from bull.net did try to massively expand the hyperv driver a few years back, but it was an awkward code dump:
https://www.redhat.com/archives/libvir-list/2014-October/msg00257.html
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Apr 18, 2016 at 09:11:24AM -0400, Cole Robinson wrote:
On 04/18/2016 08:58 AM, Daniel P. Berrange wrote:
On Mon, Apr 18, 2016 at 08:54:15AM -0400, Cole Robinson wrote:
On 04/18/2016 05:21 AM, Daniel P. Berrange wrote:
On Fri, Apr 15, 2016 at 03:54:00PM -0400, Cole Robinson wrote:
In general I'm not really in favour of dropping virt drivers for hypervisor platforms that still exist and have potential users, even if we don't hear much about them. I don't think any of these drivers is really giving us a significant maintenance headache to justify deletion.
It's just kind of a weird situation. We advertise support for these platforms, but if someone tries them and finds them lacking and reports an issue here, the only response they are going to get is 'no one has worked on it for years, no one here has a setup to test, sorry we cannot help you'. That's if they get a response at all. Seems bizarre to me...
This is implying that because we don't have an active maintainer who will answer bug reports, then the driver is entirely useless to everybody. I find that really dubious, because it ignores the possibility that people are happily using the other parts of it that actually do work. Sure it would be nice if we have active maintainers, but I don't think the lack of an active maintainer means the driver is useless to all users.
My paragraph didn't fully describe all the assumptions; Those three drivers may have zero active users in the wild. Certainly there is no obvious evidence to the contrary. The most damning bit seems to be that there hasn't been a single targeted bug fix for those drivers in an average of 4 years; if someone was actively using those drivers I'm pretty sure we would have received a drive by patch at some point
Maybe someone will chime in to prove me wrong, but what if the situation is that there's no active maintainer, and no active users? Then it truly _is_ serving no purpose, and IMO even advertising it is actively harmful since it may lead users down a dead end path
Removing a driver doesn't need to be the end either... if someone motivated shows up they can always revive the old code
As Jan points out though, that's not so easy in practice because the rest of libvirt continues evolving and so the old code won't be re-creatable without many fixups. With the current setup people who do refactoring take responsibility for fixing up all drivers. Given the number of drivers we have in tree, deleting a couple of drivers won't materially affect that effort. Someone new to libvirt though who tries to restore the old code will have to fight through all this subsequent refactoring with little domain knowledge to help them. I don't think that's really a positive tradeoff overall.
...now that I do some more targeted searches looking for patches, looks like someone from bull.net did try to massively expand the hyperv driver a few years back, but it was an awkward code dump:
https://www.redhat.com/archives/libvir-list/2014-October/msg00257.html
Oh wow, that is a huge set of enhancements - its a real shame we did not apply those, as that'd be a big step forward for hyperv. I wonder how easily they apply today.... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Eduardo Otubo -
Ján Tomko