Drop media update support in virDomainAttachDevice*

[libvirt] [PATCH 0/4][RFC] Drop media update support in virDomainAttachDevice*

Posted by Han Han 4 years, 3 months ago

https://bugzilla.redhat.com/show_bug.cgi?id=1788793

Before virDomainUpdateDeviceFlags, virDomainAttachDevice* were used for
media update. Now we have introduced virDomainUpdateDeviceFlags for 9
years(since commit 46a2ea3689) but keep that compatibility of
virDomainAttachDevice* until now.

I think it is time to remove the compatibility since it doesn't work as
well as virDomainUpdateDeviceFlags on disk xml validation.

I wonder if any uplayer software relying on this compatibility...

My git repo: https://github.com/qiankehan/libvirt/tree/attach-device-nocdrom

Han Han (4):
  virsh.rst: Mention media update is not supported in
    attach-{disk,device}
  libvirt: Remove comments of media update in virDomainAttachDeviceFlags
  qemu: Drop support of media update in live disk attach API
  libxl: Drop cdrom media update support in live disk attch APIs

 docs/manpages/virsh.rst  | 14 +++++++-------
 src/libvirt-domain.c     |  4 ----
 src/libxl/libxl_driver.c |  6 ++++--
 src/qemu/qemu_hotplug.c  | 12 ++++--------
 4 files changed, 15 insertions(+), 21 deletions(-)

-- 
2.24.0.rc1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/4][RFC] Drop media update support in virDomainAttachDevice*

Posted by Daniel P. Berrangé 4 years, 3 months ago

On Wed, Jan 15, 2020 at 04:24:54PM +0800, Han Han wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1788793
> 
> Before virDomainUpdateDeviceFlags, virDomainAttachDevice* were used for
> media update. Now we have introduced virDomainUpdateDeviceFlags for 9
> years(since commit 46a2ea3689) but keep that compatibility of
> virDomainAttachDevice* until now.
> 
> I think it is time to remove the compatibility since it doesn't work as
> well as virDomainUpdateDeviceFlags on disk xml validation.
> 
> I wonder if any uplayer software relying on this compatibility...

NACK, this is explicitly the kind of thing we will never do.

Providing a long term stable API means keeping existing methods
operating unchanged, even if we have since introduced a new method
which can do the same thing in a better way. The cost of keeping
this existing code is negligible in context to the maint work of
libvirt in general.

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