[virt-tools-list] virt-manager XML editing UI WIP

[Cole Robinson]

On 4/24/19 4:20 AM, Pavel Hrdina wrote:
> On Mon, Apr 15, 2019 at 02:51:28PM -0400, Cole Robinson wrote:
>> I published a virt-manager branch with some inprogress work to add a raw
>> XML editing UI. The code is here:
>>
>> https://github.com/crobinso/virt-manager/tree/uixml
>>
>> The implementation is a bit hacky right now, there's still some internal
>> API bits that need some thought. That branch adds it for:
>>
>> * Editing <network> XML in Connection Details
>> * Editing <pool> XML in Connection Details
>> * Editing device XML in addhardware
>>
>> There's some screenshots here: https://imgur.com/a/fduqpv6
>>
>> It's structured as a gtknotebook with two tabs
>>
>> * 'Details' which shows the existing UI in the above cases
>> * 'XML' which switches to a GtkSourceView with the XML
>>
>> It reuses the existing UI 'apply'/'finish' buttons to actually commit
>> the changes. If you edit the 'XML' and try to switch tabs before
>> 'apply'ing we warn that changes will be lost, because we don't really
>> have any way to switch back and forth between editing individual XML
>> fields and editing the XML raw. It's not the nicest looking thing but
>> it's the best I could think of that's a reusable UI pattern, and
>> reusable means it simplifies wiring this up everywhere else.
>>
>> The remaining places this can be added:
>>
>> * Details dialog for the whole <domain> XML
>> * Details dialog for individual device XML pages
>> * createnet dialog
>> * createpool dialog
>> * createvol dialog
>> * clone dialog?
>>
>> I'll also be generating a list of UI bits that I think we should drop
>> once this is in place. That will be a separate mail at some point. But
>> possibly: <network> QoS editing, <disk> driver io, <disk> driver type,
>> <disk> serial, <interface> vport stuff, likely some <graphics> options.
> 
> Hi Cole,
> 

Thanks for checking it out and commenting. First let me say I think I
understand your position because I held a similar one for a long time:

https://www.redhat.com/archives/virt-tools-list/2015-January/msg00111.html

(actually that thread continued a bit more offlist at the time and it
definitely set the idea simmering in the back of my head).

First allow me to back up a bit and give some broader context. This
might turn out to be a jumbled mess of thoughts...

virt-manager doesn't really have a focus. At various times it has
oscillated between 'expose all the knobs' and 'HIG friendly UI with no
rough edges' and there's attempts at both in the current UI.

We are never going to be either of those though. The former would be a
UI disaster, would take a ton of dev effort, be impossible to test,
<disk> alone has 50 config settings. The latter is the target usecase of
gnome-boxes which I'm happy to leave to them, plus no one is paying
money to move virt-manager in that direction anyways.

Personally I tend to think of it as a 'libvirt UI toolbox'. It should
aim to find a sweet spot between tweakability and user friendliness,
given the dev resources allocated to it (there's rarely been a full time
dev devoted to virt-manager, time is always split among other things).
UI options should only be exposed depending on factors like: how easy is
it to explain, how easy is it to use, how easy is it to abuse, what
portion of users do I expect are interested in it, how easy is it to
maintain. Stability is more important than UI improvement

That is obviously a fuzzy and subjective definition, 'sweet spot' is a
meaningless term etc. This is more or less what I use in my head though,
filtered through my own judgement and experience. Sometimes I think of
ideas we could make the UI more friendly or nicer looking, but if it's
going to take a week of work it's not really justified IMO, there's way
more important things to work on in the stack.

But we definitely need to try to narrow that definition. We need some
guidelines for potential contributors to look at so they can understand
what types of UI contributions are likely to be accepted or rejected.
Right now all they have is the current UI to go on, which is a grab bag:

* we allow adding (almost) every device, so seems like any new device is
fair game
* there's lots of disk options including several performance options, so
maybe any disk option is cool
* controller models are kinda simplified though, collapsing details down
to usb2 vs usb3
* cpu models are available but not features, what's the story there?
* the VM overview has some readonly fields and some editable and some
editable only at VM create time, not sure what to do there...
* the new VM wizard seems very deliberate so I probably shouldn't stuff
new options there...
* etc

Personally I spent much more time than expected over the past few years
reviewing UI patches. Some of those bits that were added didn't really
fit my personal intuition about what was worth exposing in the UI but I
didn't feel comfortable rejecting them because:

1) the added bit was close enough to an existing knob that I didn't feel
I could justify saying no (even if the existing knob didn't fit either IMO)

2) it's unclear to me how often the settings are actually used that I
couldn't argue confidently enough one way or the other whether it should
be in the UI or argue that virt-xml/virsh edit is enough

Recently I've tried rejecting more options, but personally it sucks and
I don't enjoy it, because I know we don't have a clear story, and the UI
is not a clear guideline so it all feels very hand wavy. And generally,
I don't think pointing to virsh and virt-xml is a fair replacement in
all situations but I'll discuss those later.

We both know that at our employer the virt-manager UI is kinda being
deprioritized and we are moving towards rejecting requests from paying
customers to add more knobs in the UI. There's also another virt
management tool in town (cockpit) with a team of people (not all working
on virt of course) and dedicated designers. Yeah it runs in a web
browser so it's a different userbase but it's slowly moving to cover a
lot of the things virt-manager already does. Honestly I think both of
these are good things

End result though is over the past year I've been thinking about
virt-manager's role long term, and how to reduce dev and maintenance
burden. And that led me to the XML editing UI. It gives us a better
story for rejecting new UI features compared to the current workaround
of 'just use virt-xml/virsh'. This also gives us a better story and
easier transition if we want to narrow the focus and remove UI knobs,
users don't need to leave the app to make changes they previously could
do from the app.

Over time that means less patches to review, less discussions to be had,
less code to write and test. I also think it will be a net win for users
but I guess that's the crux of the debate

> I've pulled your branch and tried it out to see how it looks and works.
> However, I'm still not convinced whether we should introduce something
> like that into virt-manager and drop some UI options in favor of XML
> editing.
> 
> To me personally if feels like step backwards and it will be more
> difficult to use for basic users if they will have to manually modify
> libvirt XML.
> 

I agree that we shouldn't make basic users _need_ to edit the XML, and
that's definitely not my intention. I don't think basic or intermediate
users should ever need to look at the XML.

FWIW I would define basic user VM editing tasks as things like: change
cdrom media, add a host USB device, adjust memory amount, change name or
description, maybe add an additional disk, maybe change boot order. To
me basic means 'I dont know much about virt I just want to run
$distro/windows'. And yeah we definitely aren't touching those.

As for intermediate stuff I think of things like tweaking disk
cache/discard, graphics connection details like listen on public address
+ set password, using uefi, booting off a kernel, enabling virtio 3d
accel, changing cpu model, adding some types of devices. Some more
involved config step but the user may still not have ever touched
libvirt XML before.

Anything where the user knows the XML property they are setting and are
trying to work backwards to the UI is advanced IMO. That probably covers
90% of the <domain> schema: the only people who know about the option
are likely advanced users.

> I'm not convinced whether we want to have the XML editing in
> virt-manager at all.  For one-time task where you need to edit one
> specific part of libvirt XML user can use virt-xml or simply virsh
> and if user have to do that more often they will probably have some
> script to automate that task as manual XML editing is not ideal.
> 

I agree in part. For bulk operatons virt-xml is great and can't be beat.
In the oneoff local VM case virt-xml/virsh is generally good enough.

Generally though I would much prefer saying:

'I don't think we should add X to the UI, please use the XML editor'

than:

'I don't think we should add X to the UI, please use virsh/virt-xml'

Generally telling people they don't need to leave the app is much less
friction. It's also easier to describe over email or in IRC support
making an XML change in the UI vs going to the command line, if it comes
to it. (don't need to deal with remote connections, session vs system
URI confusion, virsh editor confusion).

Those bits are kind of minor though. My main justification is up above.
But as another specific argument for the XML editor is that it enables
cases that we basically don't handle at all right now:

* XML changes at hotplug time: if you want to hotplug a device to a VM
but need an extra XML edit, going to virt-xml and/or virsh really suck.
You either have to figure out the virt-xml incantation which is
daunting, or write XML by hand and feed it to virsh. With the XML
editor, use the UI to create a template, and then edit in your custom bits

* VM install: You are creating a VM, you have some setting you _need_
but it's obscure: maybe it's disabling seclabel stuff, maybe it's a
custom edk2 rom, maybe it's some qemu commandline passthrough bug
workaround just to get the VM to boot, maybe it's a different machine
type which tweaks libvirt's default devices on first define. If you
can't set it in virt-manager and it prevents the install from even
starting or misconfigures the install, you are stuck. Now those are
fairly advanced cases but still our story is non-existent for them
presently and the XML editing is an improvement.

> This feels more like that we will add XML editing as replacement for
> new future features in UI.  It's obvious that we cannot cover all
> libvirt XML bits in our UI so we will not satisfy all users of
> virt-manager but this XML editing feels like it complicates the UI way
> too much and makes it easier for basic users to screw up their WMs.
> 
Yes my hope is that it will lead us to change the UI less in the future.
I think this is a good thing as I tried to explain above.

Yes the XML editing does complicate the UI more than the current state.
I think it's worth it though, and will be a basis for making the UI less
complicated in other ways, simplifying maintenance, and likely end in an
overall reduction in code.

Yes it's possibly easier for users to screw up their VMs, I made the
same argument once. In final implementation, with confirm before apply,
XML schema checking etc, I think we will be alright.

Also for the bits I suggested removing, here's a breakdown of my
thoughts. I hope this makes it clear that I'm not trying to remove
anything that I suspect is commonly used.

* <network> QoS editing: it's the only bit in the host network UI that
is editable. nothing against the feature specifically, but I don't think
we should have UI for editing <network> bits at all, unless it's
something very end user specific like simplifying adding a dhcp lease.
basically I think most <network> editing usecases are advanced usecases
and the XML editing UI is sufficient. If we drop the QoS bits then we
have no live editing in the current UI and it's easier to reject any
future requests for more knobs

* <disk> io threads: in my experience people never really tweak this,
the virt-manager default of 'native' for type=block is the recommended
setting. it's also totally opaque so only people that know what they are
looking for would know what it's all about. so seems fine to push to the
XML editor

* <disk> serial: Seems obscure enough that users can just set it in the
XML. I'd need to investigate a bit more though. But seems to fall under
the 'those that know they need it are advanced enough to set it in the XML'.

* <interface> vport stuff: I'd keep the UI for openvswitch which just
wants a UUID, but drop the stuff for vepa switch hardware which seems
really obscure and I seriously doubt anyone is actually using it in
virt-manager except maybe for virt testing.

* 'likely some <graphics> options': I was thinking tlsPort (because
generally who really has spice tls configured), keymap (because the
default works for most people for a decade)

Well there goes my afternoon :) I'm interested in your thoughs

Thanks,
Cole