| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
bcfg2-web will fail without setting a valid time zone in newer django versions. This fix initializes the time zone as utc instead of None, to fix most setups without directly breaking functionality.
[reporting]
TIME_ZONE = <valid_tz>
|
|
|
|
|
|
|
|
| |
Django 1.8 deprecated the multiple TEMPLATE_* settings and introduced a
single TEMPLATES config option. Django 1.10 stopped creating a
backwards-compatible TEMPLATES based on the TEMPLATE_* settings.
(See: https://docs.djangoproject.com/en/1.10/ref/templates/upgrading/#the-templates-settings)
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Python2.4 we need older version of pylint and pep8, that finds some
more errors:
- On python2.4 _ast is not available and pylint uses compiler.ast, that
seems to have some problems with the line numbers if a comment is
following the pylint disable marker.
- In python2.4 there is no xml.etree. But we can ignore this error because
Client.XML tries to find a suitable library.
- Some small formatting issues.
|
|
|
|
|
|
| |
If required the DBSettings config hook will call django.setup right after
configuring django with the required settings. So we can drop the calls to
django.setup from all other places.
|
| |
|
| |
|
|
|
|
|
| |
Django1.9 requires every app to have migrations. You cannot create a tables
without having migrations.
|
|
|
|
| |
The old name was deprecated with django1.6 and removed with django1.8.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On the first use with django-1.7 we manually get the south migration status
and fake apply the django migration to that point. With that users can switch
to django migrations at any point of time.
The code simply takes the name of the last south migration and forwards the
django migrations to that point. Therefor it is required to keep the names
of the migrations in sync.
It is required to keep the migration names of the two systems in sync.
|
| |
|
| |
|
|
|
|
|
|
| |
- reports.wsgi uses get_wsgi_application() now
- old south-based migrations have been moved
- manage.py has been updated
|
|\ |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
| |
This is mostly from 257eb0c17 and 16d3e04cb to allow for setting arbitrary
database options since some settings require nested dictionaries, etc.
This got lost during merge from maint into master because of the completely
different Options parsing.
|
|
|
|
|
| |
In the documentation, in the 1.3.x version and in django this option
is called time_zone (and not timezone). There is no reason to change this.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The database name is sometimes a path (SQLite) and sometimes not
(MySQL, PostgreSQL). This introduces a new Option type,
RepositoryMacroOption, that expands <repository> macros without
canonicalizing the path, so SQLite users can use <repository> in their
settings but MySQL users' database name settings will not be destroyed
by path canonicalization.
The unfortunate downside is that SQLite users can't use ~ in their
database name.
|
| |
|
| |
|
|
|
| |
This should eventually be a configurable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conflicts:
misc/bcfg2.spec
src/lib/Bcfg2/Client/Client.py
src/lib/Bcfg2/Client/Tools/APK.py
src/lib/Bcfg2/Client/Tools/MacPorts.py
src/lib/Bcfg2/Client/Tools/Pacman.py
src/lib/Bcfg2/Client/Tools/YUM.py
src/lib/Bcfg2/Server/Admin/Minestruct.py
src/lib/Bcfg2/Server/Admin/Pull.py
src/lib/Bcfg2/Server/Admin/Viz.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/Plugins/Cfg/CfgEncryptedGenerator.py
src/lib/Bcfg2/Server/Plugins/Cfg/CfgPrivateKeyCreator.py
src/lib/Bcfg2/Server/Plugins/Properties.py
src/lib/Bcfg2/settings.py
src/sbin/bcfg2-crypt
src/sbin/bcfg2-info
src/sbin/bcfg2-lint
src/sbin/bcfg2-yum-helper
testsuite/Testsrc/Testlib/TestServer/TestPlugins/TestCfg/TestCfgEncryptedGenerator.py
testsuite/Testsrc/Testlib/TestServer/TestPlugins/TestProperties.py
|
|
|
|
|
|
|
|
|
| |
There is a little bit of code in the reporting web interface that
uses raw SQL rather than the django ORM. This bypassed the database
router functionality (since there is no model to bind to). Django
supports keeping track of multiple connections in the raw SQL interface,
so this commit does the refactoring necessary to support the multiple
databases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This matters during the test suite:
======================================================================
ERROR: Failure: AttributeError ('Namespace' object has no attribute
'reporting_db_engine')
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/nose/loader.py", line 364, in
loadTestsFromName
addr.filename, addr.module)
File "/usr/lib/python2.6/site-packages/nose/importer.py", line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
File "/usr/lib/python2.6/site-packages/nose/importer.py", line 84, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
"/d/en/fennm-0/bcfg2-dbrouter/bcfg2-dbrouter.git/testsuite/Testtools/__init__.py",
line 14, in <module>
from common import *
File
"/d/en/fennm-0/bcfg2-dbrouter/bcfg2-dbrouter.git/testsuite/common.py",
line 62, in <module>
Bcfg2.DBSettings.finalize_django_config()
File
"/d/en/fennm-0/bcfg2-dbrouter/bcfg2-dbrouter.git/src/lib/Bcfg2/DBSettings.py",
line 99, in finalize_django_config
if opts.reporting_db_engine is not None:
AttributeError: 'Namespace' object has no attribute
'reporting_db_engine'
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Some bits of Django appear to query the options directly from the
module, even if django.conf.settings.configure() has been called
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|