[openstack-dev] [nova] How to handle hw_pointer_model image meta?

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Oct 13 17:30:37 UTC 2016


In Newton we replaced the CONF.libvirt.use_usb_tablet option with 
CONF.pointer_model, both default to creating a usb tablet input device 
for HVM guests in the libvirt driver.

To straddle backward compatibility with use_usb_tablet=False, we added 
None and ps2mouse as options for the pointer_model config option, which 
basically mean if you specify those you get whatever default input 
device there is (ps2mouse for libvirt x86).

The hw_pointer_model image metadata takes precedence over the config 
option in nova.

I noticed today that the hw_pointer_model ImageMeta object property is 
using a field with a single enum, 'usbtablet'. So while the config 
option lets you set None/ps2mouse/usbtablet, the image meta value can 
only be usbtablet if it's set.

This is important because we don't have hw_pointer_model defined in the 
glance libvirt image metadefs:

https://github.com/openstack/glance/blob/13.0.0/etc/metadefs/compute-libvirt-image.json

I'd like to add it but the only value you can have for it is 'usbtablet' 
right now. Having a single enum value seems kind of weird, but maybe 
that's fine. I only found 3 other image metadefs in glance that had 
'None' as possible enum values.

So would we define 'ps2mouse' as a hw_pointer_model option in nova or 
just add hw_pointer_model to glance and it has a single enum value for 
setting it, which is usbtablet? If you don't want usbtablet then you 
don't add hw_pointer_model to your image - HOWEVER - given we default 
CONF.pointer_model='usbtablet' we're still going to try and set it when 
creating the guest, which may or may not fail depending on your other 
config for that compute host (e.g. any non-kvm/qemu virt_type will fail).

Alternatively we could change the default value of CONF.pointer_model to 
be None and then it's purely an opt-in behavior, but it would be a 
change in default behavior for guests on kvm/qemu hosts.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list