Design discussion for interested parties. As discussed during the nova team meeting today, we're looking at providing support for virtio-based input devices in nova, given benefits w.r.t. performance and security (no emulated USB bus!). The current proposal I have for this is to introduce a new image metadata property, 'hw_input_bus', and extend the existing 'hw_pointer_model' image metadata property, which currently only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values. This means you'd end up with a matrix something like so:
+------------------+--------------+------------------------+ | hw_pointer_model | hw_input_bus | Result | +------------------|--------------+------------------------+ | - | - | PS2-based mouse [*] | | usbtablet | - | USB-based tablet | | usbtablet | usb | USB-based tablet | | usbtablet | virtio | **ERROR** | | mouse | - | USB-based mouse | | mouse | usb | USB-based mouse | | mouse | virtio | virtio-based mouse | | tablet | - | USB-based tablet | | tablet | usb | USB-based tablet | | tablet | virtio | virtio-based tablet | +------------------+--------------+------------------------+
Yeah, my complaint here is that there are too many ways to describe things that can't possibly work, in addition to the things you might ask for that aren't supported by your virt driver (which are unavoidable).
dansmith noted that the only reason to select the 'mouse' pointer model nowadays is for compatibility, and something like a virtio-based mouse didn't really make sense. That being the case, I agree that this change is likely more complex that it needs to be. We do, however, disagree on the remedy. dansmith's idea is to drop the 'hw_input_bus' image metadata property entirely and simply add a new 'virtiotablet' value to 'hw_pointer_model' instead.
Just for clarification, I want to drop the _new_ parameter from the _proposal_, as in not add it in the first place.
This still leaves the question of what bus we should use for keyboards, and his suggestion there is to extrapolate out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' is specified and presumably USB if 'hw_pointer_model=usbtablet'.
Indeed. That leaves you with no new image metadata keys, no new object structural changes, deprecation implications thereof, and just a single new value for the existing key of "virtiotablet" (or even just "virtio"). I don't really care whether or not we change the usb case from how it works today. I think most people that care a lot about how the graphical console works are probably looking for pointer support more than anything else.
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.
Right, so this is what I don't like. Users will come along trying to figure out how to get either a USB tablet or a virtio pointer, and be presented with a bunch of options. For years, google will return them results that point to the existing key that omit the new option. If they google for updated docs for that key, they won't find a new virtio-based value that they can use, but will hopefully find the explanation and truth table of how to get what they want, depending on how new or old their cloud is, what virt driver it's running, how new that virt driver is, and what platform they're using. And of course, we have to decide what to do if they specify both keys if they're confused by the forumla for deciding which to use. I'd much prefer to retain compatibility with images from the last ten years (or however long we've allowed this to be specified) and just add another value for the new model. Obviously "hw_pointer_model" isn't the nicest name, given that we're using it to determine both input devices, but I don't think that wrecking google results, docs, and people's images is really worth it. It's important to consider that people do have images and code that work on multiple clouds running various versions. It seems a lot nicer to me to just keep using the key that works everywhere, extended for the new value where available. --Dan