ConfigOpts do not verify the default values' type

Bug #1261792 reported by Wu Wenxiang
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
oslo.config
Fix Released
Low
Tom Cammann

Bug Description

Refer to https://bugs.launchpad.net/keystone/+bug/1259735

1. In keystone's codes, init a ListOpt object with a string default object, not list. And since no options appears in config file or cli, the variable 'user_attribute_ignore' will map to a string 'default_project_id,tenants', not a list. I think it's incorrect. cfg should raise a exception if default value not match the Opt types.

    keystone/common/config.py: cfg.ListOpt('user_attribute_ignore',
    keystone/common/config.py- default='default_project_id,tenants'),

2. Related Codes:
    def _get_cli_value(self, names, positional):
        for group_name, name in names:
            name = name if group_name is None else group_name + '_' + name
            try:
                value = getattr(self, name)
                if value is not None:
                    # argparse ignores default=None for nargs='*'
                    if positional and not value:
                        value = self.default
                    return value
            except AttributeError:
                pass
        raise KeyError

Tags: config
Changed in oslo:
assignee: nobody → Wu Wenxiang (wu-wenxiang)
Revision history for this message
Wu Wenxiang (wu-wenxiang) wrote :

Hello, I'm not sure if we should add logic to raise a ConfigFileValueError(Or, DefaultValueError) when got a type-error default value.
What's your opinion?
Could anyone kindly share your ideas?

Changed in oslo:
importance: Undecided → Low
status: New → Triaged
tags: added: config
Revision history for this message
Andrea Rosa (andrea-rosa-m) wrote :

I am not sure we can implement this change easily.
The risk is to break what we have at the moment, for example right now it's possible to specify for a boolean option a default value as string like 'False', if we implement this strict check we could break a running configuration.

I looked at the proposed fix https://review.openstack.org/105450 and to prove that I added this small test:
 def test_conf_file_bool_default(self):
        self.conf.register_opt(cfg.BoolOpt('foo', default='False'))
        paths = self.create_tempfiles([('test',
                                        '[DEFAULT]\n')])

        self.conf(['--config-file', paths[0]])
        self.assertTrue(hasattr(self.conf, 'foo'))
        self.assertEqual(self.conf.foo, False)

With the proposed patch it fails without it it works.
I agree that we need to add a validation for the default value, but probably we should find a way to make this validation optional and by default disable it.
Does that make sense to you?
Please note that I am not an expert for oslo.config so I probably could be totally wrong.
Thanks

affects: oslo-incubator → oslo.config
Changed in oslo.config:
assignee: Wu Wenxiang (wu-wenxiang) → Matthew Gilliard (matthew-gilliard-u)
status: Triaged → In Progress
Changed in oslo.config:
assignee: Matthew Gilliard (matthew-gilliard-u) → Tom Cammann (tom-cammann)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to oslo.config (master)

Reviewed: https://review.openstack.org/105450
Committed: https://git.openstack.org/cgit/openstack/oslo.config/commit/?id=f7c54d9ae23339f390ecc5c4410dbd705e1fbf01
Submitter: Jenkins
Branch: master

commit f7c54d9ae23339f390ecc5c4410dbd705e1fbf01
Author: Tom Cammann <email address hidden>
Date: Tue Jul 8 10:54:15 2014 +0100

    Check config default value is correct type

    Given a type of Opt, check that the default value supplied to the Opt is
    of the same type as the Opt.

    E.g. cfg.StrOpt('user_attribute_ignore', default=99) will log a warning
    as the default is not of type string.

    Closes-Bug: 1261792
    Change-Id: I12cd5f4be82ac5ed0ebb348b358dd8eaf04e4e0d

Changed in oslo.config:
status: In Progress → Fix Committed
Changed in oslo.config:
milestone: none → 1.5.0
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.