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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list