Open Stack

Excerpts from Matt Riedemann's message of 2018-03-26 14:12:52 -0500:
> 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.

So we would have to backport a feature to oslo.config to allow a list to
have choices?

> 
> 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).

What does it mean if they set the option to a list containing both
values?

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