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

[Pavel Hrdina]

On Wed, Apr 24, 2019 at 02:18:15PM -0400, Cole Robinson wrote:
> 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.

All this is a bit unfortunate for a long time, it would be nice somehow
define where virt-manager fits in the stack.  I was always considering
it as an alternative to virtualbox as there is nothing like that on top
of libvirt and QEMU/KVM.

> 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

Agreed.

> 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.

I would not say that if something takes a long time to implement that
it's not justified, but I understand that we have some priorities and
we cannot afford to spent that much time working on a new feature.

I personally don't mind to implement some feature that requires more
time, I would just dedicate one day from week to work on that feature.
Yes, it would take a month or longer but eventually the feature would
be done.

> 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

Right, the current UI is not helping at all as for some devices we have
a lot of UI options but some of the devices doesn't support anything
even though it would use new UI options.  We should probably polish that
regardless of this XML editing feature.

> 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

Yes, that's true and I'm not happy about that.  Cockpit is a nice
replacement for some remote server that you don't have to manage that
often, but for workstation usage I believe that virt-manager is still
essential, I personally don't like the idea to opening browser and
logging again into the same machine I'm using right now in order to
start/stop/install/edit VMs.

> 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.

I have an idea for a long time to introduce something like advanced
features into virt-manager, they would be hidden by default and you
would have to go to preferences to switch virt-manager into advanced
mode where we could have some non-trivial features that for example
requires some host configuration that cannot be done through libvirt.

> 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.

Agreed, this sums it up nicely.

> > 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.

Sure, these are not possible right now with virt-manager, but the
question is do we really want to allow something like that in
virt-manager UI?  Some of these advanced operations will require manual
configuration of the host so the user will have to jump out of
virt-manager regardless.  Some of these are purely isolated to libvirt
and might be interesting to more users and maybe the advanced mode could
solve it.

> > 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.

User can screw the VM even if there is a schema validation.  Basic users
will probably never touch the XML unless they will find some tutorial on
the internet where they will see some XML bit and they will try to add
it into their VMs.  Yes, they can do that now with virsh edit, but it's
an extra step that can serve as a warning to them or they will just get
scared of the fact they have to use command line and nothing bad will
happen.

> 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

Agreed, this should be removed or possible could be hidden under the
advanced mode.

> * <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

Same here.

> * <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'.

Most likely and could be possible removed.

> * <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.

Agreed.

> * '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)

The tlsPort is a big pain and like you said probably nobody is using it
as it requires manual host configuration.

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

I can definitely see the benefit of raw XML editing in virt-manager, it
would make it easier than switching to terminal and also the
remote/local and system/session connections and it may help virt
developers to test things and easily install a guest and tweak some XML
elements.

But I'm still not convinced that it's the right way to go with
virt-manager as an official supported UI element.  I would be able
to imagine the XML editing as an experimental hidden feature that you
need to explicitly enable and if something goes wrong you are on your
own.

Another downfall of the XML editing is that users might stop requesting
UI features which would make sense to add because they can simply do it
manually in the XML and they will not have enough motivation to create
a BZ.

There is a lot of work to be done in virt-manager and we have a lot of
BZs and I take it as that the tool is really used and users would like
to see improvements in the UI, yes it takes some time to process all the
bugs and patches and we will probably never gain new regular
contributors, but I still feel that it's worth the effort.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20190425/af615b7c/attachment.sig>