[virt-manager PATCH 0/3] Create pool: show only available types

[Peter Crowther]

Cole, what would you recommend as an alternative to virt-manager these
days?  It's slowly becoming apparent that the tool is moving in a direction
opposite to our interests: low-maintenance rather than high-functionality,
and where even third-party contributions aren't accepted into the codebase
because of potential future maintenance effort.  That's not a problem if
there's something else we can deploy to folks who aren't necessarily handy
with XML and a command line; it *is* a problem if there's nothing else out
there.

Or, as noted before, do we simply fork to a potentially (and deliberately)
more leading-edge tool that has a different trade-off between
functionality, maintenance, and reliability?

Cheers,

- Peter

On Mon, 7 Dec 2020 at 19:39, Cole Robinson <crobinso at redhat.com> wrote:

> On 11/24/20 9:21 AM, Pino Toscano wrote:
> > Hi,
> >
> > this series adds a minimal StoragePoolCapabilities handling using the
> > virConnect.getStoragePoolCapabilities libvirt API; this is used to
> > filter the available pool types in the "Create pool" dialog, so it does
> > not offer anymore pool types that cannot be created (as unsupported by
> > the libvirt connection).
> >
> > Pino Toscano (3):
> >   support: check for virConnect.getStoragePoolCapabilities
> >   virtinst: add a basic StoragePoolCapabilities
> >   createpool: show only available pool types
> >
> >  tests/data/capabilities/poolcaps-fs.xml | 207 ++++++++++++++++++++++++
> >  tests/test_capabilities.py              |  25 +++
> >  virtManager/createpool.py               |   7 +-
> >  virtinst/__init__.py                    |   1 +
> >  virtinst/storagepoolcapabilities.py     |  61 +++++++
> >  virtinst/support.py                     |   2 +
> >  6 files changed, 302 insertions(+), 1 deletion(-)
> >  create mode 100644 tests/data/capabilities/poolcaps-fs.xml
> >  create mode 100644 virtinst/storagepoolcapabilities.py
> >
>
> The code looks fine but I am conflicted about this. I'm not sure it's
> worth adding code to read and process storage capabilities XML at all.
> I'd rather see the storage dialogs become smaller, not more
> featureful/smarter at the cost of increased maintenance and potential
> for future feature creep. For example sheepdog and mpath can be dropped
> entirely IMO. rbd pool creation should probably be dropped because the
> UI is never going to be comprehensive enough to handle the common case
> which requires specifying an auth secret. Same may apply to gluster but
> I'd need to double check.
>
> As implemented I'm a little iffy on the UI too. Just hiding options
> without giving the user a hint can cause confusion, like why is FOO
> available as a pool option for one connection but not the other. There's
> ways to fix it but at the cost of more code with goes back to my point
> above.
>
> Can you explain your motivation a bit: Has this caused you issues
> before? Or is there something more useful in the storage XML that you
> want to add support for afterwards?
>
> Thanks,
> Cole
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20201207/d6ed623b/attachment.htm>