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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
