| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
misc/bcfg2.spec
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| |\
| | |
| | | |
Reporting: start a new thread for each import
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |\
| | |/
| |/|
| | | |
reporting-thread-each-data-import
|
| | | |
|
| |\ \
| | | |
| | | | |
Tests: Fix tests after 9a6a231
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This ensures consistency between the in-memory representation of
clients.xml and the representation on disk. If we don't read our
writes immediately, there's a race condition when creating a new
client: If it asserts its profile or version before the FAM event from
the clients.xml edit is processed, then the clients doesn't appear to
exist yet, and Bcfg2 complains.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
| | | | |
|
| | | | |
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
The addition of the call to load_xml in 9a6a231 causes the test to
fail because load_xml() expects to read a clients.xml file. The
actual actual open calls in write_xml are dummied out with Mock,
so no file is written, and thus cannot be read back. This commit
dummies out the load_xml and adds some more asserts for good measure.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
AWSTags allows querying tags from EC2, and setting groups based on the
tag names or values.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
By default, el5 doesn't have the %%rhel macro, provided by the
buildsys-macros package.
EPEL build servers install buildsys-macros by default, but explicitly
requiring it may help builds in other environments
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Apparently I made up %elif.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Both old init scripts and new systemd units
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- remove %{__install} and other such macros, no longer used in Fedora
- use init scripts from redhat/scripts rather than debian
- systemd unit file installation
- install Examples
- move %check section up
- fix some macros
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
specfile reconciliation w/Fedora:
Sol Jerome requested the differences between misc/bcfg2.spec and the
Fedora specfile be reconciled as much as possible. This will
hopefully make updates easier for distro packagers (like me), and also
help keep misc/bcfg2.spec up to date.
The approach is to pick one feature at a time and massage both
upstream and Fedora versions so that they match as much as possible
after several easy-to-understand commits on each side. Beneficial
features present in one but not the other will be preserved in both.
Unfortunately, they will never match perfectly since misc/bcfg2.spec
maintains support for non-RedHat distros. I believe Fedora Packaging
Guidelines does not permit the extra macros (this statement should be
verified). An additional goal is to make the diff between the two
minimal and easy to read.
------------------
- Rearrange %package sections
- Add bcfg2-examples package
- Reconcile Summary: and Group: tags
- Remove unneeded Version: tags from subpackages
|
| | |
|