On Mon, Apr 19, 2021 at 02:45:52PM +0200, Pavel Hrdina wrote: > On Mon, Apr 19, 2021 at 01:24:26PM +0200, Peter Krempa wrote: > > On Mon, Apr 19, 2021 at 13:12:07 +0200, Pavel Hrdina wrote: > > > On Mon, Apr 19, 2021 at 12:53:11PM +0200, Peter Krempa wrote: > > > > On Mon, Apr 19, 2021 at 12:47:59 +0200, Pavel Hrdina wrote: > > > > > Upstream sheepdog project doesn't have any active development for almost > > > > > 3 years as the last commit is from 28/06/2018 [1]. > > > > > > > > > > Looking into repology [2] the latest version 1.0.1 is included only in > > > > > Fedora (since Fedora 26). There are only few other distributions having > > > > > older sheepdog versions: Debian oldstable (stretch), EPEL 6, Ubuntu > > > > > 18.04 and older and few other less-common distributions. > > > > > > > > > > Based on the data above drop support for sheepdog from libvirt. > > > > > > > > > > [1] <https://github.com/sheepdog/sheepdog/commits/master> > > > > > [2] <https://repology.org/project/sheepdog/versions> > > > > > > > > > > Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> > > > > > --- > > > > > docs/formatdomain.rst | 13 +- > > > > > docs/formatstorage.html.in | 5 +- > > > > > docs/kbase/rpm-deployment.rst | 6 - > > > > > docs/manpages/virsh.rst | 7 +- > > > > > docs/schemas/domaincommon.rng | 1 - > > > > > docs/schemas/storagepool.rng | 22 - > > > > > docs/storage.html.in | 59 --- > > > > > libvirt.spec.in | 36 -- > > > > > meson.build | 6 - > > > > > meson_options.txt | 1 - > > > > > mingw-libvirt.spec.in | 1 - > > > > > po/POTFILES.in | 1 - > > > > > src/conf/domain_conf.c | 1 - > > > > > src/conf/storage_conf.c | 12 +- > > > > > src/conf/storage_conf.h | 2 - > > > > > src/conf/storage_source_conf.c | 4 - > > > > > src/conf/storage_source_conf.h | 1 - > > > > > src/conf/virstorageobj.c | 9 - > > > > > src/libvirt-storage.c | 1 - > > > > > src/libxl/libxl_conf.c | 1 - > > > > > src/libxl/xen_xl.c | 1 - > > > > > src/qemu/qemu_block.c | 41 -- > > > > > src/qemu/qemu_command.c | 20 - > > > > > src/qemu/qemu_domain.c | 1 - > > > > > src/qemu/qemu_snapshot.c | 3 - > > > > > src/storage/meson.build | 25 -- > > > > > src/storage/storage_backend.c | 6 - > > > > > src/storage/storage_backend_sheepdog.c | 378 ------------------ > > > > > src/storage/storage_backend_sheepdog.h | 25 -- > > > > > src/storage/storage_backend_sheepdog_priv.h | 30 -- > > > > > src/storage/storage_driver.c | 1 - > > > > > .../storage_source_backingstore.c | 44 -- > > > > > src/test/test_driver.c | 1 - > > > > > tests/meson.build | 6 - > > > > > tests/qemublocktest.c | 4 - > > > > > .../imagecreate/network-sheepdog-qcow2.json | 20 - > > > > > .../imagecreate/network-sheepdog-qcow2.xml | 12 - > > > > > tests/qemusecuritytest.c | 1 - > > > > > .../disk-network-sheepdog.args | 30 -- > > > > > .../disk-network-sheepdog.x86_64-2.12.0.args | 34 -- > > > > > .../disk-network-sheepdog.x86_64-latest.args | 38 -- > > > > > .../disk-network-sheepdog.xml | 37 -- > > > > > tests/qemuxml2argvtest.c | 3 - > > > > > .../disk-network-sheepdog.xml | 43 -- > > > > > tests/qemuxml2xmltest.c | 1 - > > > > > tests/storagebackendsheepdogtest.c | 206 ---------- > > > > > .../storagepoolcapsschemadata/poolcaps-fs.xml | 2 - > > > > > .../poolcaps-full.xml | 2 - > > > > > tests/storagepoolxml2argvtest.c | 2 - > > > > > tests/storagepoolxml2xmlin/pool-sheepdog.xml | 8 - > > > > > tests/storagepoolxml2xmlout/pool-sheepdog.xml | 11 - > > > > > tests/storagepoolxml2xmltest.c | 1 - > > > > > tests/storagevolxml2xmlin/vol-sheepdog.xml | 10 - > > > > > tests/storagevolxml2xmlout/vol-sheepdog.xml | 8 - > > > > > tests/storagevolxml2xmltest.c | 1 - > > > > > .../deflatten-qemu-sheepdog-in.json | 11 - > > > > > .../deflatten-qemu-sheepdog-out.json | 13 - > > > > > tests/virjsontest.c | 1 - > > > > > tests/virstoragetest.c | 21 - > > > > > tools/virsh-pool.c | 3 - > > > > > tools/virsh.c | 3 - > > > > > 61 files changed, 8 insertions(+), 1289 deletions(-) > > > > > delete mode 100644 src/storage/storage_backend_sheepdog.c > > > > > delete mode 100644 src/storage/storage_backend_sheepdog.h > > > > > delete mode 100644 src/storage/storage_backend_sheepdog_priv.h > > > > > delete mode 100644 tests/qemublocktestdata/imagecreate/network-sheepdog-qcow2.json > > > > > delete mode 100644 tests/qemublocktestdata/imagecreate/network-sheepdog-qcow2.xml > > > > > delete mode 100644 tests/qemuxml2argvdata/disk-network-sheepdog.args > > > > > delete mode 100644 tests/qemuxml2argvdata/disk-network-sheepdog.x86_64-2.12.0.args > > > > > delete mode 100644 tests/qemuxml2argvdata/disk-network-sheepdog.x86_64-latest.args > > > > > delete mode 100644 tests/qemuxml2argvdata/disk-network-sheepdog.xml > > > > > delete mode 100644 tests/qemuxml2xmloutdata/disk-network-sheepdog.xml > > > > > delete mode 100644 tests/storagebackendsheepdogtest.c > > > > > delete mode 100644 tests/storagepoolxml2xmlin/pool-sheepdog.xml > > > > > delete mode 100644 tests/storagepoolxml2xmlout/pool-sheepdog.xml > > > > > delete mode 100644 tests/storagevolxml2xmlin/vol-sheepdog.xml > > > > > delete mode 100644 tests/storagevolxml2xmlout/vol-sheepdog.xml > > > > > delete mode 100644 tests/virjsondata/deflatten-qemu-sheepdog-in.json > > > > > delete mode 100644 tests/virjsondata/deflatten-qemu-sheepdog-out.json > > > > > > > > While I don't have any problems with removing the sheepdog storage > > > > driver I don't think we should remove both the storage driver and qemu > > > > driver interactions in one commit and at the same time I also don't > > > > > > Make sense, I'll split it into separate commits. > > > > > > > think we should remove the support for launching QEMU guests with > > > > sheepdog backing as that has negligible maint burden. > > > > > > Well it is marked as deprecated in QEMU [1] so I don't agree with this > > > argument. We would eventually drop it from libvirt as well once it is > > > removed from QEMU and I don't see any reason keeping the code in libvirt > > > for something that doesn't have any future. > > > > Our usuall approach is that until we support a qemu version which does > > support the feature, we should keep the code. Same way we keep code for > > vxhs storage driver despite it being removed already in qemu upstream. > > In some cases it would be nice to have an exception to the support > policy. I doubt we have users for qemu sheepdog backend. The point of the policy is that we can never answer these kind of usage questions in any definitive sense - there's always doubt at what users might exist and what they have deployed. The support policy gives us an unambiguous way to decide whether to keep/remove functionality without having to debate unanswerable questions, and likewise gives users the knowledge about the likely lifetime of support. 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 :|
