c0746040e3
If Zuul receives replication events and is configured to wait for them (by setting a positive timeout value) the gerrit connection will now wait for replication to report completion before processing the related events. This should allow Zuul deployments to rely on their replicas for Zuul git operations. While Zuul's test suite seems to indicate this works there are some things to keep in mind. We can only associate replication and primary events using project,ref tuples. This means that if many updates are made to the same project,ref simultaneously Zuul must wait for all of them to complete before processing any of the primary events. Additionally, Gerrit replicas may have different performance and Zuul may not talk to all of them. A potential followup improvement would be to specify a matcher to match against replica names to limit the replicas to only those that impact Zuul. Change-Id: Ie1dfccac1f5a088547caa999352811ad6842f3e5
40 lines
811 B
Plaintext
40 lines
811 B
Plaintext
[statsd]
|
|
# note, use 127.0.0.1 rather than localhost to avoid getting ipv6
|
|
# see: https://github.com/jsocol/pystatsd/issues/61
|
|
server=127.0.0.1
|
|
|
|
[scheduler]
|
|
tenant_config=main.yaml
|
|
|
|
[merger]
|
|
git_dir=/tmp/zuul-test/merger-git
|
|
git_user_email=zuul@example.com
|
|
git_user_name=zuul
|
|
|
|
[web]
|
|
root=http://zuul.example.com
|
|
|
|
[executor]
|
|
git_dir=/tmp/zuul-test/executor-git
|
|
load_multiplier=100
|
|
|
|
[connection gerrit]
|
|
driver=gerrit
|
|
server=review.example.com
|
|
user=jenkins
|
|
sshkey=fake_id_rsa_path
|
|
password=badpassword
|
|
# This is longer than our test case timeout so that we can ensure
|
|
# test cases aren't magically working because replication timed out.
|
|
replication_timeout=300
|
|
|
|
[connection smtp]
|
|
driver=smtp
|
|
server=localhost
|
|
port=25
|
|
default_from=zuul@example.com
|
|
default_to=you@example.com
|
|
|
|
[database]
|
|
dburi=$MYSQL_FIXTURE_DBURI$
|