This change introduces a mechanism to allow reloading of the
@GerritServerConfig. To execute a reload of gerrit.config, the SSH
command "reload-config" is provided.
Challenges and implementation:
------------------------------
Most callers that inject @GerritServerConfig are @Singletons. These
@Singletons will only parse the GerritServerConfig once and then
build and store more suitable datastructures to work from.
To allow these modules to react on config changes, a caller can now
implement GerritConfigListener, which will enable the caller to receive
notifications of future config updates.
The GerritConfigListener provides:
void configUpdated(ConfigUpdatedEvent event);
The ConfigUpdatedEvent provides the old config and the new one.
Implementing classes of the listener are expected to do three things:
1. Investigate if any of the updated config values are of interest.
The ConfigUpdatedEvent provides helper methods for this purpose:
public boolean isSectionUpdated(String section)
public boolean isValueUpdated(String section, String subsection, String name)
(+ various overloaded versions of these)
2. React to the configuration changes (if any) and apply them
3. Accept or reject the entries of interest:
public void accept(Set<ConfigKey> entries)
public void accept(String section)
public void reject(Set<ConfigKey> entries)
(+ various overloaded versions of these)
When a section (or specific config keys) are accepted or rejected, the
ConfigUpdatedEvent will build a diff of what changes were accepted and
present it to the administrator that issued a configuration reload.
For instance, in this case, 4 config rows where added(+), 2 removed(-1)
and 1 modified. All but one change were accepted, hence the user would get
this output:
$ ssh $HOST -p 29418 gerrit reload-config
Accepted configuration changes:
- suggest.maxSuggestedReviewers = 10
- suggest.accounts = 50
* addreviewer.maxAllowed = [100 => 1000]
+ sshd.requestLog = true
+ commentlink.changeid.link = #/q/$1
+ commentlink.changeid.match = (I[0-9a-f]{8,40})
Rejected configuration changes:
+ gc.startTime = Fri 10:30
Documentation:
--------------
We start by documenting the config entries that support config reloads
(which number will be increasing over time).
When we support reloading of the majority of config settings, the
documentation can switch to documenting the config entries that does
_not_ support config reloading instead.
Roadmap:
--------
This change will be followed by a couple of changes that introduces
reloadable config support for: suggest-reviewers, sshd-log and
commentlinks.
Other stuff TODO includes:
* REST end point
* Rejection messages (to allow for an explanation on why the value was
not accepted)
* Test cases
* An option to allow displaying the current effective configuration
* A lot of implementations of the GerritConfigListener.
Change-Id: I4bd6f389731af303ef9ba5d1d73f173d869c62e4
Without this, a plugin failing to load might break other unrelated
plugins. This occurs because a Guice environment is created and a
serverManager is created but never started.
This should only be triggered when a bogus plugin is installed, which
is more likely to occur during plugin development.
Also initialize the fields outside of the constructor.
Change-Id: I0bcbe331697e320430711a776357800f1f69c8a3
This is the first change in a series that intends to getting rid of
refs/for/ from ACLs.
The migration from "push refs/for/*" to "create-review refs/heads/*"
is handled on-the-fly when the configuration is loaded.
Any "push refs/for/*" permission will be automatially migrated to the
new "Create Review" permission and the old permission will be removed
if possible (e.g. push refs/* will create a new Create Review permission,
but keep the old permission since it will affect refs/{heads,meta}/*).
When the rest of the refs/for/ dependent permissions are migrated, an
offline schema migration should be available to help correct all configs,
though the online auto migration should be available for a few major
versions to help fix ACL-mistakes by users.
Change-Id: Ia112adeb7593a7b4a7a8b5d8b96f72f73c9b70b8
If a change query doesn’t contain any index predicate, but only post
filter predicates the query result was limited to open changes only.
E.g. “reviewerin:Users” was finding only open changes while
“reviewerin:Users message:foo” considered open and closed changes. This
behaviour was confusing users.
Bug: Issue 8597
Change-Id: I88d93d60a5572345a4c4e8a5d58628b4c1a4851d
Signed-off-by: Edwin Kempin <ekempin@google.com>
Using PostFilterPredicate better describes what these predicates do,
they post filter the result of change queries. With this change the
behaviour doesn’t change, especially for queries with a post filter
predicate but no index predicate we still fall back to query only open
changes. This should be addressed in a follow-up change.
Change-Id: I6527e15777c174e7616a56a82fdd1c69ad98f9c5
Signed-off-by: Edwin Kempin <ekempin@google.com>
The old set of saveProjectConfig methods is rather unsafe:
* It was possible to pass in a ProjectConfig corresponding to a
different project than the Project.NameKey passed to the same method.
I know I have written tests that failed because I mixed up the config
and name with allProjects vs. project.
* Convenience methods like allow would read the ProjectState from the
ProjectCache and mutate its ProjectConfig in-place. This would be
highly unsafe to do in a real server where the cached ProjectState is
accessed from multiple threads; we're just lucky that this only
happened in a single-threaded test context, and the project cache was
always subsequently flushed.
* Many callers elsewhere in various tests emulated this bad behavior of
reading from the cache.
This change introduces a new test utility ProjectConfigUpdate which
handles opening the MetaDataUpdate, saving and evicting, and closing
when finished. This may not be the ideal interface we ultimately end up
with for updating project configs, but it's definitely safer and cleaner
than the status quo, and migrating callers was simple and mechanical.
Change-Id: Id4ad7bcdafa2b61a23bc09f10a703bbf358820d4
The lazyLoad field has no javadoc on it, so a link to it is not useful.
(Eclipse also complains that the field itself is private).
Change-Id: Ibf82481539bcfddda8c61ccac13edac77a8f9720
This commit implements a per-request cache as a per-thread cache.
PerThreadCache is intended to cache objects that have a high
instantiation cost, are specific to the current request and
potentially need to be instantiated multiple times while serving a
request.
The implementation uses a ThreadLocal which limits the cache to
the serving thread. Given that fan-outs (like ChangeJson's executor)
run with high parallelization, it seems acceptable to re-do some
instantiation there in lieu of this cache.
This commit uses a the new cache in DefaultPermissionBackend to cache
a ProjectControl instance.
Change-Id: Id5de21ed8941c7e08eb37197b16ce2cadece7aea
The newly created thread pool should be used for parallelizing
work from request serving threads.
This is a fairly large pool that makes it less likely that
ReviewerRecommender uses a congested queue.
Change-Id: Ie229ef98c33ec475b94fc76d8fc2bd0c0872465a
Loading accounts from disk if they are not present in the cache
is OK for single accounts but creates significant latency burden
when multiple accounts need to be loaded.
This commit adds a method to AccountCache that allows for
parallelization and implements it on a new executor in
AccountCacheImpl.
Change-Id: I1b58b2f71c8b1c62e809314e6c50ac1b25a3a166
99%ile latency of QueryChanges is between 20 seconds and
80 seconds on googlesource.com depending on the time of
day. There are two main reasons for that:
1) Performing operations that require loading ChangeNotes
2) Performing operations that require opening the repo
3) Filling accounts with a cold AccountCache
This commit parallelizes formatting the individual results
to mitigate 1+2. 3 will be addressed by a different change
that will make the AccountFiller parallelize, too.
Parallelization is done on a newly introduced FanOutExectuor
that can be used whenever a serving thread wants to parallelize
work.
Change-Id: I36c6b92e31488ad001f5aea43efc837d31ba3021
getCacheKey() can be used when grouping objects by user in caches. The
first user of this new method is a PerThreadCache added in a later commit.
Change-Id: I00a9c1528e2fdd2219f511ba749074efe9d967b6
This is needed for the replication plugin which will need to serialize
GitReferenceUpdatedListener.Event objects into json and deserialize them
as the implementation class GitReferenceUpdated.Event.
Change-Id: I672fc34841d7da2c26067ec9eccd608a15f934a9
Practically speaking, the CheckAccess endpoint is annoying for use in
administrative actions, because it requires the right Content-Type
headers.
Philosophically, the endpoint only inspects, so it should not use the
POST method.
Change-Id: I5270b683f51f2876785ba84e762b7ecedbceea21
This capability can be assigned separately so users can run check.access
without having to be admin.
Change-Id: I29a7c8d637a606ce9f7cf353ba242b1c43c2682b
