| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes two related bugs: One causes Metadata to use an out-of-date
cached list of clients when a client is deleted or added with
bcfg2-admin; the other causes child worker processes to use an
out-of-date cached list of clients when a client is added with a Bcfg2
run when the multiprocessing core is in use.
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The caching facilities in Bcfg2.Server.Cache provided basically no
features. This rewrites that to allow for much more powerful cache
expiration, with a particular focus on interoperation between
different components and plugins to let caches be expired as
necessary. (E.g., the Probes plugin can expire the Metadata cache.)
This does not affect any of the file data cached by Bcfg2, only the
caches that are populated with arbitrary data (Metadata, Packages,
Probes, etc.).
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/lib/Bcfg2/Server/Admin/Viz.py
src/lib/Bcfg2/Server/Plugins/Packages/__init__.py
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Also abstracted getting the list of objects that may register RMI
calls into a separate function.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This gives a single unified interface for expiring caches, no matter
the plugin. This will be particularly useful with the
MultiprocessingCore, as certain calls must be dispatched to child
processes to expire their caches.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This proxies RecvProbeData calls to child cores to expire the probe
cache. The probe data itself is not relayed, just the fact that there
was probe data received from a given client.
Fixes #129.
|
| |
| |
| |
| | |
non-thread-safe bits
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
performance
|
| |
| |
| |
| | |
powerful)
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
When the broker in a multiprocessing configuration expires its
metadata cache (e.g., when probe data is received), it must dispatch
that expiration call to its children.
This also makes the protocol for communication between the broker and
its children into a real RPC protocol, so we can do even more stuff in
the future.
|
| |
|
|
|