c1671a7e026a8264080de2adc5a937d2d12be842: ansible/hg-web: remove support for running on CentOS 6
Gregory Szorc <gps@mozilla.com> - Wed, 31 Aug 2016 15:41:42 -0700 - rev 690909
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
ansible/hg-web: remove support for running on CentOS 6 d0dac75fe203 removed the last CentOS 6 user of this role. Drop support for running on CentOS 6. MozReview-Commit-ID: Bb2GTwZagc3
d0dac75fe2030880a393c4b3a99a38fd0ca8bc57: docker: build hgweb container for MozReview with CentOS 7
Gregory Szorc <gps@mozilla.com> - Wed, 31 Aug 2016 10:23:54 -0700 - rev 690908
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
docker: build hgweb container for MozReview with CentOS 7 The hgweb container uses CentOS 7 canonically. I'm actually surprised it still builds with CentOS 6. Or maybe this is dead code... Either way, this makes the configuration consistent.
dc45e8509d11137d5a84fe6bad77095b1f0142f8: ansible/hg-ssh: remove ius-repo dependency
Gregory Szorc <gps@mozilla.com> - Wed, 31 Aug 2016 10:17:41 -0700 - rev 690907
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
ansible/hg-ssh: remove ius-repo dependency hg-ssh only runs on CentOS 7 now. This code was only running on CentOS 6. Nuke it.
09f460206ff6dbf3b45aa7665edacdd75777cd08: ansible: install Mercurial RPMs via a role
Gregory Szorc <gps@mozilla.com> - Wed, 31 Aug 2016 10:40:45 -0700 - rev 690906
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
ansible: install Mercurial RPMs via a role Before, the code for installing Mercurial from RPMs was duplicated across a number of places. We had a mercurial-yum role, but it only supported CentOS 6 and wasn't used a lot. Make it support CentOS 7 and switch to using it everywhere.
265ed4a82ee9c953d58cd5f184f4690ecabc4066: mozreview: don't show stack when pushing merges (bug 1298992); r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 29 Aug 2016 17:09:34 -0700 - rev 690905
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
mozreview: don't show stack when pushing merges (bug 1298992); r=glandium It appears the behavior of git-cinnabar or git-mozreview changed in the past few months with regards to error handling during `git mozreview push`. Today, Python code in git-cinnabar raises an uncaught exception in `cinnabar-debug-push.py`. This causes Python to print the traceback and exit 1. This output is then printed to the user. That is arguably an acceptable outcome for legitimate bugs. However, the known case of pushing merges results in the traceback, and that is a poor user experience. We add code to detect the exception raised from pushing merges and convert it to an explicit exit code which is gracefully turned into an abort without displaying the traceback. Sniffing exception messages isn't a great way to detect error type. But cinnabar lives us no choice since it raises a generic Exception (and who can fault it - you shouldn't have to consume its internal API). MozReview-Commit-ID: 8foHdIHWOFs
e583d9a175eed8d86326fc5e568800a22a23e92b: testing: build the cinnabar helper (bug 1298992); r=glandium
Gregory Szorc <gps@mozilla.com> - Mon, 29 Aug 2016 16:36:12 -0700 - rev 690904
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
testing: build the cinnabar helper (bug 1298992); r=glandium cinnabar now displays a warning message when running cinnabar functionality without the cinnabar helper. Rather than disable the warning message, let's build the helper since installs in the wild are recommended to use the helper. MozReview-Commit-ID: 1xl84CjDYBk
5fe72b1660d117df0d160a1172ba5aa6ebb04104: testing: move MySQL socket to a tmpfs volume (bug 1299294); r=glob
Gregory Szorc <gps@mozilla.com> - Tue, 30 Aug 2016 14:06:56 -0700 - rev 690903
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
testing: move MySQL socket to a tmpfs volume (bug 1299294); r=glob overlayfs and UNIX domain sockets don't play well together. Move the MySQL socket to a known tmpfs mount to avoid problems. Before this change, my machine at home was seeing a lot of random failures connecting to MySQL when running tests concurrently. Afterwards, the errors seem to have gone away. Chalk this hack up to "because Docker." MozReview-Commit-ID: 4DEy4P2F1rV
248f564f85031394f387f7ddd289f3127de5c39b: mozreviewbots: update test output to reflect reality
Gregory Szorc <gps@mozilla.com> - Tue, 30 Aug 2016 15:32:36 -0700 - rev 690902
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
mozreviewbots: update test output to reflect reality Minor changes to test output appear to have snuck in over time. These aren't significant enough to warrant review IMO. MozReview-Commit-ID: HiMbCf9Gu8y
cd6fe64296b41a3ee05981ae7f8440a10596b75a: firefoxtree: update tests to reflect changed repo lists (bug 1299011)
Gregory Szorc <gps@mozilla.com> - Tue, 30 Aug 2016 14:04:50 -0700 - rev 690901
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
firefoxtree: update tests to reflect changed repo lists (bug 1299011) 7b32540df088 changed mozautomation's lists of repos. This impacted firefoxtree's test output. Update the test output to match reality.
3af0c0fbd9ad5efc27bf459690f4e31380fec320: docker: use user-defined network for mozreview cluster (bug 1290783); r=glob
Gregory Szorc <gps@mozilla.com> - Mon, 29 Aug 2016 10:48:05 -0700 - rev 690900
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
docker: use user-defined network for mozreview cluster (bug 1290783); r=glob Docker 1.12 requires things like links to be specified at container create time instead of start time. If we were to retain using links, we would have to drastically overhaul the container startup sequence. And this would undo a lot of optimizations around our startup sequence, which currently creates containers as early as possible to cut down on start time. Fortunately, there's a better way. Newer versions of Docker support "user-defined networks." These are essentially named, isolated networks. When using user-defined networks, containers that join networks can specify "aliases." These magically get turned into resolveable hostnames inside all containers in that network. This is a really cool feature because it means hostnames and port numbers can be static within the network. Before, you would have to sniff environment variables at container start time to resolve IPs/hostnames and ports. With constant aliases in user-defined networks, you can hardcode both the hostname and the port. This commit switches the MozReview cluster to use user-defined networks. The network name is randomly generated. Containers in the network have aliases giving each a sane hostname. A lot of code around configuring containers at startup for dynamic hostnames and ports has been removed since these are now static properties. There is certainly follow-up work to remove more code around container startup that was needed for the dynamic environment. But I'll defer that to another day. I've tested this commit on Docker 1.11 and 1.12 and it appears to "just work" on both. I would have liked to split the changes to docker.py into a smaller commit. But Docker 1.11 didn't like moving host config to container create time without also changing the networking config. MozReview-Commit-ID: 18dH4CSPj5n
d508328c4ff86d3369533fd909525ff8846ff89b: testing: change link name of autoland db from "db" to "autolanddb"; r=glob
Gregory Szorc <gps@mozilla.com> - Mon, 29 Aug 2016 10:47:48 -0700 - rev 690899
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
testing: change link name of autoland db from "db" to "autolanddb"; r=glob Making it more descriptive in the context of a larger cluster. MozReview-Commit-ID: Ag4d6F5uVOs
283c32907b0e724e9875354ebce69a70a5aacb90: pushlog: make compatible with Mercurial 3.8 (bug 1298555); r=smacleod
Gregory Szorc <gps@mozilla.com> - Fri, 26 Aug 2016 17:17:31 -0700 - rev 690898
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
pushlog: make compatible with Mercurial 3.8 (bug 1298555); r=smacleod Mercurial 3.8 dropped revset.extpredicate for registrar.revsetpredicate and made it so you don't need to call setup() on it. Make pushlog compatible with Mercurial 3.8. While I'm here, I also verified that pushlog is compatible with Mercurial 3.9, so marking it accordingly. MozReview-Commit-ID: Iu0IjCMGVtw
4ca271431a51efe5597fd2fbd26096a2db381aec: testing: unpin bmo revision and update path to generate_bmo_data.pl (bug 1298524) r=gps
byron jones <glob@mozilla.com> - Tue, 30 Aug 2016 13:21:56 +0800 - rev 690897
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
testing: unpin bmo revision and update path to generate_bmo_data.pl (bug 1298524) r=gps MozReview-Commit-ID: 4BxgJbVzF0b
7b32540df0888e7cb8e76e6daccedee3f11fb149: Mark several repositories as obsolete (bug 1299011) r=gps
Wes Kocher <wkocher@mozilla.com> - Mon, 29 Aug 2016 18:12:35 -0700 - rev 690896
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
Mark several repositories as obsolete (bug 1299011) r=gps MozReview-Commit-ID: 3x2o31e4SEu
4e3776c0e713ba9b0da7f5bdcbf23ce4eb7ca4ba: Bug 1298567 - Encode UI outputs. r=gps
Akihiko Odaki <akihiko.odaki.4i@stu.hosei.ac.jp> - Tue, 30 Aug 2016 10:50:59 +0900 - rev 690895
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
Bug 1298567 - Encode UI outputs. r=gps MozReview-Commit-ID: 1jsIgkZktAx
a1d6b78f698b840d5744ef43050cbee8e85afb18: docker: extract function for obtaining a network config into own function
Gregory Szorc <gps@mozilla.com> - Mon, 29 Aug 2016 10:21:32 -0700 - rev 690894
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
docker: extract function for obtaining a network config into own function
70b95c696bd2913dceee9fdfbfecf4e17bbeaea0: hgmo: eliminate race condition on kafka topic availability
Gregory Szorc <gps@mozilla.com> - Fri, 26 Aug 2016 18:38:18 -0700 - rev 690893
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
hgmo: eliminate race condition on kafka topic availability Before, there was a race condition in the hgmo cluster between creating a Kafka topic and that topic becoming usable. This resulted in intermittent "UnknownTopicOrPartition" errors, especially when running many tests concurrently. We add code to cluster startup to wait for topic metadata to become available. This appears to be sufficient to eliminate the race condition. With this change, I no longer see UnknownTopicOrPartition errors when running 6 tests concurrently. Before, I used to get 2+ failures per test run. MozReview-Commit-ID: ExPzMAiM3Mq
1b436f40fc5ac5d23c3ea72d652f37e84d81c21c: hgmo: don't wait on ldap and pulse containers
Gregory Szorc <gps@mozilla.com> - Fri, 26 Aug 2016 17:55:23 -0700 - rev 690892
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
hgmo: don't wait on ldap and pulse containers Now that we are using user-defined networks, we don't need to wait on containers to start before we can proceed with subsequent container start. So stop waiting on the ldap and pulse containers to start before starting the hgweb containers. MozReview-Commit-ID: GIHfb5k5naG
20445e213b9a8d09e4a3cc1ad3ba8e752a701076: docker: create bmo container in user-defined network
Gregory Szorc <gps@mozilla.com> - Fri, 26 Aug 2016 15:57:59 -0700 - rev 690891
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
docker: create bmo container in user-defined network We're moving everything to user-defined networks because they are a better alternative to links since you can define aliases in each network that automagically resolve. Move the standalone BMO container to start in a user-defined network. MozReview-Commit-ID: 2Y6HJV0orUT
770d659df221cb1a70fa9a6c7832e8834a80f791: docker: detect docker hostname more robustly
Gregory Szorc <gps@mozilla.com> - Fri, 19 Aug 2016 20:55:27 -0700 - rev 690890
Push 87314 by gszorc@mozilla.com at Thu, 02 Nov 2017 02:08:10 +0000
docker: detect docker hostname more robustly The Docker hostname can be set to "localhost" or "127.0.0.1" in some situations. This will confuse things when we're using user-defined networking. Change the Docker hostname detection logic to prefer the bridge network in these scenarios. MozReview-Commit-ID: 9YCP7Xe67B5
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip