[openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?

melanie witt melwittt at gmail.com
Mon Mar 26 19:28:02 UTC 2018

On Mon, 26 Mar 2018 14:12:52 -0500, Matt Riedemann wrote:
> 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.

I'm not sure if this helps, but we do already have some example of a 
ListOpt with 'choices' for the VNC auth_schemes:


Could we do something similar for the backport of the CPU flags patch?


More information about the OpenStack-dev mailing list