Slave configuration overhaul

[TimN]

While working with Bitten and configuring the slave some short comings became clear and I'd like to propose some changes to solve this.

The base problem is that I wanted to store the user credentials in the configuration rather than giving them on the command line. Since the slave is basically running all the time the user credentials would be exposed to all other users logged in on that system.

So I started hacking on the slave by adding a [slave] config section. Unfortunately currently all sections that are expected are hard-coded into the Configuration class, at least by the sections to skip as packages... This makes it rather nasty if you want to have a generic configuration framework.

Because of this I'd like to propose the basic changes:

• Sections can have any name, the values can in general be queried with config['section.option'], thus the values are not flattened into one namespace. This will make the OS name "os.name".
• Package sections are encoded as [package:package_name] where the package: prefix indicates that this is a package section. The package_name is what you currently have. Package values can then be queried as config['package_name:option'].

This way not a single section name has to be hardcoded into Configuration, there is still support for any number of packages and package options. Extending the configuration of the slave to new fields is then trivial.

[TimN]

Patch with generalized configuration class

[TimN]

I have added a small patch with makes the proposed changes. It keeps the default sysinfo values around and just merges them before reading the config file.

It also throws away the properties that have not been used anywhere and that were just producing many unused lines of code. But that may be added easily to the patch if necessary. I have done preliminary tests and it seems to work so far. I tweaked the form login patch to support Trac auth credentials from the config file, which is a 3-line patch with the new patched Configuration class.

Another thing that came to my mind that would be helpful to add is a bitten.d config directory, in which arbitrary configurations can reside which will all be merged to one. I noticed that when building packages for Fedora of bitten. I like the OS to be Fedora with the version being the Fedora version number (currently 8). Since a specific distro version like "Fedora 8" tells you a lot more than just "Linux 2.6.23...". Also this config directory would allow for one config file per package which makes it easier for auto provisioning of systems.

Let me know what you think.

[dfraser]

Note that equivalent functionality was requested in #374, and I committed the patch from there in r619 as it was simpler without adjusting the general config.

If you feel these patches still apply, can you check them against current trunk and say so?

[dfraser]

Dropping priority till we get a response...

[osimons]

I've added documentation for all aspects of configuration: Documentation/configure.html. As far as I can see, the current configuration subsystem can handle any need expressed in this ticket.

The dot-notation is only used to separate default provided options from custom options, and describing the custom options as 'package options' is just terminology - in practice they can be used for runtime settings, recipe interpolation and target platform rules.

I'm closing this ticket as 'worksforme', but please reopen if there is something I've overlooked or misunderstood.