Open Stack

On Fri, Jun 17, 2016 at 03:36:53PM -0500, Matt Riedemann wrote:
> I was reviewing the last change in this blueprint series today:
> 
> https://review.openstack.org/#/c/174854/
> 
> And started to question why we even have a config option for this anymore.
> The blueprint didn't have a spec but there are some details in the
> description about the use cases:
> 
> https://blueprints.launchpad.net/nova/+spec/virt-configure-usb-tablet-from-image
> 
> From the code and help text for the option I realize that there is some
> per-compute enablement required for this to work (VNC or SPICE enabled and
> the SPICE agent disabled). But otherwise it seems totally image-specific,
> which is why the blueprint is adding support for calculating whether or not
> to enable USB support in the guest based on the image metadata properties.
> 
> But do we still need the configuration option then?
> 
> The tricky scenario I have in mind is I create my Windows instance on a host
> that has use_usb_table=True and I can use my USB pointer mouse and I'm
> happy, yay! Then that host goes under maintenance, the admin migrates it to
> another host that has use_usb_tablet=False and now I can't use my USB mouse
> anymore. I guess the chance of this happening are pretty slim given
> use_usb_tablet defaults to True.
> 
> However, in https://review.openstack.org/#/c/176242/ use_usb_table is
> deprecated in favor of the new 'pointer_model' config option which defaults
> to None, so it's not backward compatible with use_usb_tablet and when we
> remove use_usb_tablet as an option in Ocata, the default behavior has
> changed.

We did not wanted set a default value for pointer_model, as you
indicated before it's something more related to the guest images, we
only want give to operators ability to set a default behavior.

Also operators who use the option 'usbtablet' will be warn for an
entire release to update to pointer_model option.

> Anyway, my point is, why do we even need a config option for this at all if
> the image metadata can tell us what to do now?

I don't see any problem to let operators decide what is the hosts
default behavior.

s.

> -- 
> 
> Thanks,
> 
> Matt Riedemann