Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
On Mon, Mar 26, 2018 at 12:28:02PM -0700, melanie witt wrote: > 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: > > https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L229 > > Could we do something similar for the backport of the CPU flags patch? Ah, interesting pointer. It seems to work locally, and I updated the patch with it[*]: [...] cfg.ListOpt( 'cpu_model_extra_flags', item_type=types.String( choices=['pcid'] ), default=[], help=""" ... """ [...] Thanks, Melanie. [*] https://review.openstack.org/#/c/534384/ -- /kashyap __ 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
Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
Excerpts from melanie witt's message of 2018-03-26 12:28:02 -0700: > 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: > > https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L229 > > Could we do something similar for the backport of the CPU flags patch? > > -melanie > Oh, look, another feature that's already in the library. :-) Doug __ 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
Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
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
Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
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: https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L229 Could we do something similar for the backport of the CPU flags patch? -melanie __ 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
Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
There is no special reasons that ListOpt doesn't allow parameter, PortOpt also uses parameter 'choices'. PortOpt and StrOpt only accept one value and use this parameter to double check value is valid which is in the 'choices'. 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 2018-03-26 17:49 GMT+08:00 Kashyap Chamarthy : > Hi there, > > I was looking at oslo_config/cfg.py[*], and the StrOpt() class has > 'choices' parameter, to allow a sequence of valid values / tuples of > valid values for descriptions. > > However, I don't see the same 'choices' parameter for the ListOpt() > class. Out of curiosity, is there a reason to not add it for ListOpt() > too? > > [*] https://git.openstack.org/cgit/openstack/oslo.config/ > tree/oslo_config/cfg.py#n1271 > > -- > /kashyap > > __ > 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 > -- ChangBo Guo(gcb) Community Director @EasyStack __ 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
[openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
Hi there, I was looking at oslo_config/cfg.py[*], and the StrOpt() class has 'choices' parameter, to allow a sequence of valid values / tuples of valid values for descriptions. However, I don't see the same 'choices' parameter for the ListOpt() class. Out of curiosity, is there a reason to not add it for ListOpt() too? [*] https://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n1271 -- /kashyap __ 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
