Core GS config.
Project description
- Contact:
- Michael JasonSmith <mpj17@onlinegroups.net>
- Date:
- 2015-03-17
- Organization:
- GroupServer.org
- Copyright:
- This document is licensed under a Creative Commons Attribution-Share Alike 4.0 International License by OnlineGroups.net.
Introduction
Sometimes configuration is complex, such as when multiple sets of configuration is needed because multiple instances of a system (such as GroupServer [1]) are running on the same setup. In this case each instance is made up of a set of components, and each component is made up of configuration options:
Instance
Component
Configuration options
More configuration options
Component 2
Different configuration options
Another instance
Sadly the ConfigParser system does not allow for this hierarchy, but gs.config does, by using the name space to provide the relationship between an instance and the component. In particular, this product supplies a Config class to read a file of a particular structure.
Config Class
The gs.config.Config class that represents the system configuration. See the Sphinx documentation in this module for more information.
File
The instance is marked with the name [config-${name}], where ${name} is the name of the instance. For example [config-production] for the instance production.
For each component the set of sections is then supplied:
[config-production] database = production smtp = external cache = production tokenauth = production
The configuration for a component can be shared by multiple instances:
[config-staging] database = production smtp = dead cache = none tokenauth = production
Each component is a configuration section, with a name of the form [${component}-${name}]. For example [smtp-external] for the smtp section named external.
Example
In the example below three instances are configured: one for a test-server, one for a staging server, and one for a production server. Each instance has two components: a database, and an SMTP server:
[config-test] database = test smtp = test [config-staging] database = live smtp = test [config-production] database = live smtp = live # An actual configuration section for each configuration set [database-test] dsn = postgres://name:pass@server/database-test [database-live] dsn = postgres://name:pass@server/database-live [smtp-test] server = localhost port = 2525 [smtp-live] server = external port = 25
When the configuration is instantiated, an ID is passed. This ID identifies the configuration set that is currently being accessed. If an ID is not passed, an attempt is made to get the ID from the environment automatically. At the moment this is specific to the GroupServer environment, though care is taken to ensure that it will fall back gracefully to being passed an ID.
Resources
Documentation: http://groupserver.readthedocs.org/projects/gsconfig
Code repository: https://github.com/groupserver/gs.config
Questions and comments to http://groupserver.org/groups/development
Report bugs at https://redmine.iopen.net/projects/groupserver
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
