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