GitLocker: The Coding Marketplace

Description:

gs.config 2.1.2

Authors:
Richard Waid
Michael JasonSmith

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

[1]
While originally written for GroupServer, there is no
code in this product that is specific to
GroupServer. However, this product is used to configure
the database, SMTP, cache, and token
authentication for GroupServer.