Open Stack

On 11/16/20 02:41, Stephen Finucane wrote:
> On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote:
>> Needless to say, I don't like this idea and prefer we took another
>> tack
>> and kept 'hw_input_bus'  but didn't build on 'hw_pointer_model' and
>> instead "deprecated" it. We can't really ever remove the an image
>> metadata property, since that would be a breaking upgrade, which
>> means
>> we'll eventually be left with effectively dead code to maintain
>> forever. However, I don't think that's a big deal.
>> 'hw_pointer_model=usbtablet' is already on a path to obsolescence as
>> the Q35 machine type slowly becomes the default on x86 hosts and the
>> use of non-x86 hosts grows since neither support PS2 and must use a
>> USB-based input device. In addition, I think the extrapolation of
>> 'virtiotablet' to mean also virtio-based keyboard is unclear and
>> leaves
>> a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64
>> hosts (where it's currently added by default), since we don't
>> currently
>> do this extrapolation and introducing it would be breaking change on
>> x86 hosts (instances would suddenly switch from PS2-based keyboards
>> to
>> USB-based ones).

For some reason your email didn't quote my inline replies when you 
replied back, so I'm going to label them for clarity.

melwitt:
> If I understand correctly, we do choose the "best fit" keyboard based
> on architecture, independent of the requested hw_pointer_model, today.

stephenfin:
> Not quite. libvirt on x86 will automatically add a PS2 mouse and
> keyboard (even if you request something else) because that's what QEMU
> does. On all other platforms (to the best of my knowledge, based on
> Kashyap quizzing a handful of multi-arch libvirt devs), this must be
> done manually. We currently only do this for AArch64, through the non-
> configurable addition of a USB keyboard [1]. There is currently no way
> to request e.g. a USB or virtio keyboard on any architecture.
> 
> [1] https://github.com/openstack/nova/commit/b92e3bc95fd

Hm, OK, apologies for my lack of familiarity here. So there are really 
three things here: tablet, mouse, and keyboard. And the user today can 
choose hw_pointer_model as None (leave it to default behavior) or 
usbtablet which sets the input.type=tablet and the input.bus=usb. And 
then the mouse and keyboard are set to whatever they have to be given 
the architecture.

melwitt:
> It feels like it would be simpler to continue doing that and add a
> virtio choice to hw_pointer_model and let the driver pick the "best"
> keyboard to go along with that. Is it your view that having the
>> driver choose a virtio keyboard if hw_pointer_model=virtiotablet is
>> inconsistent with the existing "best fit" keyboard selection
>> behavior?

stephenfin:
> My concerns are twofold. Firstly, having the value of
> 'hw_pointer_model' influence the keyboard bus is poor UX, since this
> "feature" is not at all apparent from the property name. Secondly,
> 'hw_pointer_model' is a poorly designed property, given it configured
> the bus as well as the model, munging the two.
> 
> To be clear, I agree that having different buses for keyboard and
> pointer makes no sense. There's no reason they shouldn't be the same.
> I'm just saying that configuring the bus for input devices via an
> appropriately named 'hw_input_bus' image metadata property makes much
> more sense that maybe getting one configured magically based on the
> "pointer model" in use.

OK, so the introduction of virtio would be the first time that we would 
be able to set all of tablet, mouse, and keyboard to the same bus. What 
if they don't want all three input devices, could it cause any 
undesirable behavior for them?

And then if they set hw_input_bus=usb for libvirt on x86 they'd get a 
USB tablet, a PS2 mouse, and a PS2 keyboard and on AArch64 they'd get a 
USB tablet, ? mouse, and USB keyboard.

I dunno, it's all pretty confusing IMHO. My point in my last reply was 
that for the libvirt on x86 case, if the user sets hw_input_bus=usb, how 
would they know they're really only specifying the tablet? Today they 
use hw_pointer_model=usbtablet which makes it clear what they have 
control over. I acknowledge that for hw_input_bus=virtio, things all 
line up nicely, but for everything else, it doesn't necessarily.

This makes me think it would be clearest and least confusing (IMHO) to 
add a new option like dansmith mentioned, hw_pointer_model=virtio. That 
way it's not talking only about a tablet but generically just 'virtio' 
and then all of tablet, mouse, and keyboard get added with bus=virtio.

melwitt:
>  From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent.

stephenfin:
> Again, not really. There isn't an analog for pointer vs. mouse when it
> comes to keyboards. The keyboard isn't architecture dependent. What is
> architecture dependent is whether you get a keyboard and mouse by
> default (yes on x86, in the form of a PS2 mouse and keyboard, and no
> for everyone else).

melwitt:
>> If we "deprecated" hw_pointer_model and introduced hw_input_bus, how does
>> the user know which thing (pointer or keyboard) they are specifying?
>> If users can't actually choose the keyboard and can only choose the pointer,
> wouldn't presenting a selection of a generic "hw_input_bus" be more confusing
>> than hw_pointer_model?

stephenfin:
> They can choose the _bus_ that the keyboard uses. There's an assumption
> here that if you request a graphics device (VNC, SPICE, ...) then you
> will get a keyboard and tablet input devices, because that graphics
> device is unusable otherwise. There is also an assumption (based on
> dansmith's comments about mouse being only used for legacy compat
> reasons) that the user will never want to explicitly request a 'mouse'
> pointer model and should therefore get 'tablet' by default. Based on
> these two assumptions, the only thing remaining is to decide how the
> keyboard and tablet devices will be attached to the guest...achieved
> via a sensibly named 'hw_input_bus' image metadata property. That seems
> reasonable to me.

I hope I'm not woefully wrong here again, but IIUC they can't choose the 
bus the mouse and keyboard uses for libvirt on x86, they get PS2 
regardless. This is why I feel like hw_input_bus as a replacement for 
hw_pointer_model is not clear. It's only guaranteed to be used for the 
tablet bus.

I'm sorry I'm not seeing how hw_pointer_model=virtio isn't the clearest, 
least confusing way to add virtio. (Or maybe 
hw_pointer_model=virtiotabletmousekeyboard ?!)

Thanks for taking the time to explain the technical details around this 
area of the code. I think I now understand your point of view since the 
name of hw_pointer_model doesn't nicely convey the tablet+mouse+keyboard 
setting when it comes to virtio. On the flip side of that, I feel like 
hw_input_bus=usb when it's only going to be honored for the tablet for 
libvirt on x86 seems even less nice.

This is all just MHO. If most other people think that hw_input_bus is 
the clearer and more user-friendly way to present this config, then I 
will of course accept the consensus.

Cheers,
-melanie

>> We need to decide what approach to go for before I rework this. If
>> anyone has input, particularly operators that think they'd use this
>> feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶
>> ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel
>> free to either reply here or on the review [1].
>>
>> Cheers,
>> Stephen
>>
>> [1] https://review.opendev.org/#/c/756552/
>>
>>
> 
> 
>