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(a)redhat.com>
> > > > ---
> > > > 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
--
|: