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