| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements a Django database router which routes each
Django application to a database whose name matches a key in the database
dict, falling back to the default database if no matching key is found.
This support is plumbed through to the config file via
database.reporting_* database connection config options. These options
mirror ones available for the default database config. If
database.reporting_engine is not specified in the config, then the
configuration falls back to the traditional single-database way of doing
things with the database router becoming a no-op.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_set_defaults_from_config must be called before _parse_config_options
This is due to a tricky interaction between the two methods:
(1) _set_defaults_from_config does what its name implies, it updates
the "default" property of each Option based on the value that exists
in the config.
(2) _parse_config_options will look at each option and set it to the
default value that is _currently_ defined. If the option does not
exist in the namespace, it will be added. The method carefully
avoids overwriting the value of an option that is already defined in
the namespace.
Thus, if _set_defaults_from_config has not been called yet when
_parse_config_options is called, all config file options will get set
to their hardcoded defaults. This process defines the options in the
namespace and _parse_config_options will never look at them again.
|
|
|
|
| |
This is to make the method name more in line with what it does
|
| |
|
|
|
|
|
| |
This ensures that /etc/bcfg2-web.conf gets read, even if the
--web-config for [reporting].config options are not given
|
|
|
|
|
| |
Some bits of Django appear to query the options directly from the
module, even if django.conf.settings.configure() has been called
|
|
|
|
| |
This also fixes some extraneous calls in the option parsing loop.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Older clients used to depend on this because there was no backported
python-ssl module available for various platforms. All supported
platforms now appear to either a) have the backported module or b) have
a recent enough version of python to use the builtin ssl module.
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/appendix/guides/fedora.txt
misc/bcfg2.spec
schemas/types.xsd
src/lib/Bcfg2/Encryption.py
src/lib/Bcfg2/Options.py
src/lib/Bcfg2/Server/Admin/Client.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/Lint/Validate.py
src/lib/Bcfg2/Server/Plugin/helpers.py
src/lib/Bcfg2/Server/Plugins/Bundler.py
src/lib/Bcfg2/Server/Plugins/Cfg/CfgEncryptedGenerator.py
src/lib/Bcfg2/Server/Plugins/Probes.py
src/sbin/bcfg2-crypt
testsuite/Testsrc/Testlib/TestServer/TestPlugin/Testhelpers.py
testsuite/Testsrc/Testlib/TestServer/TestPlugins/TestCfg/TestCfgEncryptedGenerator.py
testsuite/Testsrc/Testlib/TestServer/TestPlugins/TestProbes.py
testsuite/common.py
testsuite/install.sh
|
| |
| |
| |
| |
| | |
This plugin validates the JSON files that can be used by Properties
and Ohai.
|
| |
| |
| |
| |
| |
| |
| |
| | |
TemplateAbuse detects templated scripts (either files that end with a
known extension, or that start with a shebang line) and executables
(based off of their permissions in info.xml) and warns about them,
since templating scripts is dicey at best, and almost always better
done by templating a config file for the script to read instead.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Previously, if CfgEncryptedGenerator was imported before the Cfg
object was instantiated, it would finalize the
Bcfg2.Server.Plugins.Cfg.SETUP object with a value of None, and would
be unable to access the options dict.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This mimics the behavior for "real" tools
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Plugins that use the database often act quite differently depending on
whether or not the database is enabled. If we start the server
without the database (e.g., the connection failed), then Very Strange
Things can happen.
|
| | |
|
| |
| |
| |
| | |
functionality
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
lxml 3.2.1 complains when you try to parse a unicode (in Python 2) or
string (in Python 3) containing an XML document with an encoding
declaration. Traceback:
ValueError: Unicode strings with encoding declaration are not
supported. Please use bytes input or XML fragments without
declaration.
This encodes the document as a string (in Python 2) or bytes (in
Python 3) to avoid the lxml error. There may be other places this
happens, too, although in most other cases we should use
lxml.etree.parse() to parse a file, or we parse strings (in Python 2)
instead of unicode objects.
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
If finalize is called early, then some options will not be parsed
but instead always take the default value (observed with
reporting.transport). Calling finalize once at the end of the
processing lets all options take the values they were assigned in the
config file.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This prevents the hostgroup list from flipping at random.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/lib/Bcfg2/Server/Admin/Reports.py
src/lib/Bcfg2/Server/Hostbase/hostbase/urls.py
src/lib/Bcfg2/Server/Hostbase/urls.py
src/sbin/bcfg2-crypt
tools/upgrade/1.3/migrate_dbstats.py
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
|
| | |
|