On 12/7/20 5:18 PM, Peter Crowther wrote: > 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? > I can't tell if this is a legitimate question or you were trying to make a point, but the other desktop UI tools in libvirt space I know of are gnome-boxes and qt-virt-manager (no relation). I'm sure there's others but those are the only two that have crossed my radar in the past five years that are actively maintained. I'm curious do any of the bits I mentioned dropping actually matter for your usecase? Creating storage pools outside of the simple dir/fs usecases is pretty niche in my experience. For the case like ceph to even get it working as a storage pool you either need to have pretty strong understanding of libvirt XML, or you are copy+pasting XML from an online source, in which case having clicky (and limited) UI doesn't add much over the XML editor or the command line. - Cole > Cheers, > > - Peter > > On Mon, 7 Dec 2020 at 19:39, Cole Robinson <crobinso@xxxxxxxxxx > <mailto:crobinso@xxxxxxxxxx>> 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 > - Cole
