Comment 1 for bug 1046923

Here's a simple example of a config file:

[DEFAULT]
version = 0.13.7
plugins = checkbox/plugins

[checkbox/plugins]
modules = %(checkbox_share)s/plugins/*.py

[checkbox/plugins/jobs_info]
blacklist = autotest/full_suite ltp phoronix qa-regression-testing
    clone06.1 ioctl03.1 lchown02.* swapon03.1

I see two ways to munge a config file:

- Messing up the format. If this happens the parser will throw an exception (see here for possible exceptions: http://docs.python.org/py3k/library/configparser.html?highlight=configparser#exceptions). It doesn't look like checkbox is handling these explicitly, but I find they're clear enough to figure out there's something wrong with the .ini file. If the syntax is really that messed up, you probably don't want to run checkbox anyway as it will probably fail horribly.

- A valid format that makes no semantic sense. For instance, setting a value that doesn't exist in a plugin due to maybe forgetting the header.

[checkbox/plugins/info_prompt]
welcome_message = "something"

#Notice a section missing here, so blacklist will be set on info_prompt, which has no blacklist attribute
blacklist = autotest/full_suite ltp phoronix qa-regression-testing
    clone06.1 ioctl03.1 lchown02.* swapon03.1

Since these values are simply set as class variables, and the admissible per-plugin keys are not declared anywhere, there's currently no way a plugin can know if it receives a class variable that wasn't meant for it. This verification would, I think, have to be done at the plugin level.

I got all this from just reading the code, so I'll set this to Triaged, and work to do:

- Research what happens if a plugin receives a setting it's not supposed to have.
- Decide if it's worth adding a list (a simple list would suffice, I think) of valid config items for each plugin, and having a mechanism that barfs if an invalid or unexpected item is set.
- Decide what to do in this case: does checkbox just exit, log a warning, show a message in the UI.