Open Stack

On Wed, 2020-11-18 at 16:12 -0800, melanie witt wrote:
> 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.

Looks like Evolution has broken plain text editing :( Apologies.

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

Sort of. As above, you'll get the PS2 keyboard for free on x86. You'll
get a USB keyboard on AArch64. You won't get anything on any other
arch.

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

You don't have any choice: if you have a graphical console, you need a
pointer (mouse or tablet) and you need a keyboard for it to be usable.
Conversely, if you don't have a graphical console, then we've no need
to add either. If a user didn't want a mouse and keyboard then they can
and should disable graphical consoles.

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

No, on x86 you'd get a USB tablet and keyboard, and a PS2 mouse PS2
keyboard. This is because there isn't currently a way to disable the
PS2 devices in libvirt/QEMU. However, this is not an issue since the
guest OS will default to using the USB-based devices (or so danpb tells
me). Also note that this is very similar to how things currently work
with 'hw_pointer_model=usbtablet': setting this means you'll get a USB
tablet (but not keyboard), and a PS2 mouse and keyboard.

On AArch64 and any other non-x86 host, they'd get simply a USB tablet
and a USB keyboard because libvirt doesn't have that QEMU quirk to work
with.

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

As above, they're not. hw_input_bus means USB keyboard and tablet on
any host. The only arch that will do something weird is x86, where we
have those pesky PS2 remnants that we can't get rid of.

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

Given the above, do you still have the same concerns around using
hw_input_bus?

Cheers,
Stephen

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201120/05487ec2/attachment-0001.html>