Checkbox gives no feedback if a config file is invalid

Bug #1046923 reported by Brendan Donegan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Checkbox (Legacy)
Won't Fix
Low
Unassigned

Bug Description

It's possible to mess up a config file and Checkbox will not tell you anything about it. There should be clear feedback (an error) when config files are incorrect.

For example the header of a plugin section might be forgotten and then the values won't be set in the plugin - Checkbox should warn about this at least.

Revision history for this message
Daniel Manrique (roadmr) wrote :

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.

Changed in checkbox:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

This is fixed in plainbox.

Zygmunt Krynicki (zyga)
affects: checkbox → checkbox-legacy
Changed in checkbox-legacy:
status: Triaged → Won't Fix
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.