| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Add option to limit the count of child threads to import the transactions.
If the number is exceeded the next import will block until one thread is
ready.
|
|
|
|
|
|
|
|
|
|
|
| |
The interaction entries have a isstale() method, we do not need a
template tag, that tries to figure out this on its own. The isstale()
method works even better: It knows, if the interaction is the current
interaction and compares the timestamp to the current time or (if it is
not the current one) it compares the timestamp to the timestamp of the
next interaction. So using the method of the model, you can browse the
interaction history and see, if the host was stale some time in the
past. Previously all interactions more than 24h ago were marked stale.
|
|\
| |
| |
| | |
https://github.com/AlexanderS/bcfg2
|
| |
| |
| |
| |
| | |
Highligh additional special hosts in the grid view. Stale hosts get a
grey background and clean hosts with extra packages get a blue background.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| | |
Add a new column "stale", that displays if a host is stale or not. It could be
determined by parsing the date column, but it would be more convenient to
have a separate column for that.
|
|/
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
Conflicts:
doc/appendix/guides/import-existing-ssh-keys.txt
misc/bcfg2.spec
src/lib/Bcfg2/Client/Tools/VCS.py
src/lib/Bcfg2/Client/Tools/YUM.py
src/lib/Bcfg2/Encryption.py
src/lib/Bcfg2/Reporting/Collector.py
src/lib/Bcfg2/Reporting/Storage/DjangoORM.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/FileMonitor/__init__.py
src/lib/Bcfg2/Server/Lint/RequiredAttrs.py
src/lib/Bcfg2/Server/Plugin/helpers.py
src/lib/Bcfg2/Server/Plugins/Metadata.py
src/lib/Bcfg2/Server/Plugins/Packages/Yum.py
src/lib/Bcfg2/Server/Plugins/Packages/__init__.py
src/lib/Bcfg2/settings.py
src/sbin/bcfg2-crypt
src/sbin/bcfg2-reports
src/sbin/bcfg2-yum-helper
testsuite/Testsrc/Testlib/TestClient/TestTools/TestPOSIX/TestAugeas.py
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Close the db connection at the end of each DjangoORM import, not when
the reporting collector shuts down. The collector may not have even
opened a connection, in the case of a storage backend other than
DjangoORM.
Fixes #157
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
I noticed that, at least on Python 2.4, memory for threads doesn't
get freed until the threads are joined. This patch causes the
collector to periodically go through and reap those threads.
Tested in production for ~1 month, no reported issues.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 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.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/lib/Bcfg2/Server/Admin/Compare.py
src/lib/Bcfg2/Server/Admin/Snapshots.py
src/lib/Bcfg2/Server/MultiprocessingCore.py
src/lib/Bcfg2/Server/Plugins/Probes.py
src/sbin/bcfg2-crypt
src/sbin/bcfg2-reports
tools/upgrade/1.3/migrate_configs.py
tools/upgrade/1.3/migrate_perms_to_mode.py
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | |
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/development/lint.txt
misc/bcfg2.spec
src/lib/Bcfg2/Reporting/Collector.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/Plugins/Metadata.py
src/lib/Bcfg2/Server/models.py
testsuite/install.sh
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f813f86f8ac2bc7b55f4eb6a0d936f1ce4f68ba7. Premature
optimization is the root of all evil, etc.
Conflicts:
src/lib/Bcfg2/Reporting/Collector.py
|
| |
| |
| |
| |
| |
| | |
1. Use a better convention for calling the threading.Thread constructor
2. Add docstring to ReportingStoreThread.run
3. Give the storage thread variable a better name
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When dealing with a high-latency database connection (eg. across a
WAN), the bcfg2-report-collector process can fall behind in its
import queue. The imports are very much bound by the response
latency of the database server and not processing throughput.
This patch fires off a new thread for each database interaction.
The thread itself simply falls out of scope when the interaction
is finished processing. The interaction object is still read from
the disk serially in order avoid having to create a locking mechanism
for that part of the process.
This change does potentially create greater load on the database
server, but ultimately the load is limited by rate at which the
bcfg2 server can generate work.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
Conflicts:
src/lib/Bcfg2/Client/Tools/__init__.py
src/lib/Bcfg2/Server/BuiltinCore.py
src/lib/Bcfg2/Server/Plugins/Metadata.py
src/lib/Bcfg2/Server/Plugins/NagiosGen.py
src/lib/Bcfg2/Server/Plugins/Probes.py
src/lib/Bcfg2/Server/SSLServer.py
tools/README
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Following the same logic as 360ba2e7, we should be explicit about
the need to detach the bcfg2-report-collector process.
Side note: this bit me because I was starting the bcfg2 server
processes via SSH, and the way python-daemon checks for being
started by inetd is to see if stdin is a socket. (??)
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/lib/Bcfg2/Server/Admin/Viz.py
src/lib/Bcfg2/Server/Plugins/Packages/__init__.py
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/lib/Bcfg2/Client/Frame.py
src/lib/Bcfg2/Options.py
src/lib/Bcfg2/Server/Admin/Init.py
src/lib/Bcfg2/Server/Admin/Xcmd.py
src/lib/Bcfg2/Server/BuiltinCore.py
src/lib/Bcfg2/Server/Core.py
src/lib/Bcfg2/Server/MultiprocessingCore.py
src/lib/Bcfg2/Server/Plugin/base.py
src/lib/Bcfg2/Server/Plugin/helpers.py
src/lib/Bcfg2/Server/Plugins/Cfg/__init__.py
src/lib/Bcfg2/Server/Plugins/Packages/Yum.py
src/lib/Bcfg2/Server/Plugins/Packages/__init__.py
src/lib/Bcfg2/Server/SSLServer.py
src/lib/Bcfg2/Utils.py
src/lib/Bcfg2/settings.py
src/sbin/bcfg2-crypt
src/sbin/bcfg2-info
src/sbin/bcfg2-lint
src/sbin/bcfg2-test
src/sbin/bcfg2-yum-helper
tools/bcfg2-profile-templates.py
|
| | |
|
|/
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|