[virt-tools-list] RFC: virt-manager feature removals

[Cole Robinson]

On 6/24/19 5:09 AM, Daniel P. Berrangé wrote:
> On Fri, Jun 21, 2019 at 07:14:56PM -0400, Cole Robinson wrote:
>> On 6/19/19 6:34 PM, Cole Robinson wrote:
>>> Hi all,
>>>
>>> I've drafted a wiki page about virt-manager UI philosophy, for lack of a
>>> better term, suggestions welcome. The intention here is to provide some
>>> guidance about what types of things we want to expose in the UI, both to
>>> devs, potential contributors, and users requesting RFEs.
>>>
>>> https://github.com/virt-manager/virt-manager/wiki/WIP-UI-philosophy
>>
>> Following on from the UI philosophy document, here's a list of features
>> in current virt-manager/virt-install features that I think are
>> candidates for removal.
> 
>> * the migration wizard: migration is IMO an advanced use case. It
>> requires host config outside of virt-manager to have a chance of
>> working. the only place migration is really critical for users is
>> serious multihost production scenarios where virt-manager isn't really
>> appropriate per the UI philosophy. And besides some UI friendliness
>> virt-manager doesn't really add much over virsh IMO. Nearly every bug I
>> can recall about its usage was from one person who happens to be a
>> co-worker developing qemu migration, and redhat QE, which means it's
>> either perfect or no one uses it :) I think it should go
> 
> I'm not really convinced by this, as I think it dumbs down virt-manager
> too much. Telling GUI users to use virsh instead is not a very compelling
> story IMHO. virt-manager has multi-host as a feature, and so I think it
> is reasonable to expect it to support migration. It isn't only large
> openstack scale deployments that can find it useful. 
> 

Okay. Given you and Peter's rejection I'm fine with keeping it, it's
fairly low maintenance anyways.

> 
>> * console scaling options (always, never, fullscreen): we've had this in
>> the UI forever, but I don't think it has much usage. virt-viewer doesn't
>> even expose it how we do, instead it just has a zoom option which I
>> don't think we need to implement either. just today there was a bug
>> reported saying that scale->always is fairly obviously broken and has
>> been for a few releases, which makes me think no one is using it.
>> dropping this could be part of a larger think of how console sizing
>> works, if we should default to spice auto-resize, or if there's some
>> more modern config we should be taking care of.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1722088
> 
> The right answer is different for VNC vs SPICE.
> 
> For VNC you just want to resize the main window to fit, if possible,
> otherwise scale it down. No compelling reason to want to be scaling up.
> 
> For SPICE though if the guest agent is present then you want to guest
> display to auto-resize to match whatever the host window allows to
> display. That way you never need scaling down.
> 

Okay. If I ever make time to give a bigger rethink how we handle console
resizing by default, I will make a thread

>> * graphics keymap stuff. in virtinst/hostkeymap.py we have some logic
>> to parse host keymap from various locations like /etc/vconsole.conf and
>> try to map it to a qemu keymap name. You can trigger this via the UI in
>> the keymap dropdown 'Copy local keymap' and via virt-install --graphics
>> keymap=local, though the latter isn't even documented. This all was
>> the default behavior we used and essentially needed years ago, but
>> qemu and spice-gtk/gtk-vnc have for a decade been able to route
>> around the need by sending raw scancodes back and forth. This code
>> could in theory still be valuable for someone to set the keymap to
>> work with a vncviewer for example which doesn't have the scancode
>> support IIRC, but I think at that point we can just ask them to specify
>> the keymap themselves. So I propose killing hostkeymap entirely, making
>> keymap=local print a cli warning, and drop the keymap dropdown from the
>> UI. Users can set it in the XML editor if they need it
> 
> Yes, there's no compelling reason to set the keymap - even non-gtk-vnc
> based clients like tigervnc support the scancode mode now.

That's good to hear

Thanks,
Cole