Open Stack

On 3/26/2018 6:24 AM, ChangBo Guo wrote:
> What's your use case for ListOpt, just make sure the value(a list) is 
> part of  'choices' ?   Maybe we need another parameter to distinguish

It came up because of this change in nova:

https://review.openstack.org/#/c/534384/

We want to backport that as a bug fix which is a mitigation for 
performance degradation issues with QEMU patches for Spectre and Meltdown.

However, in the backport we wanted to restrict the ListOpt to a single 
value, "pcid". The idea is to restrict the new option to a single value 
in stable branches.

Then in master, we could remove the 'choices' kwarg so operators can 
define their list as they wish.

If we were do implement this generically in ListOpt, I suppose 'choices' 
would mean that the specified list must be a subset of the defined 
choices list. So in the backport patch, we'd just have choices=[None, 
'pcid'] and you can either specify None or 'pcied' for that option 
(default to None).

Right now the code that's relying on this option just has a hard-coded 
check for the value which is OK.

-- 

Thanks,

Matt