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