Previously we sent it always as "data", which caused problems for GET
requests where there is no request body.
(imported from commit 20084d1da1b8228cc484536ca4d6f77f547a9d78)
We also switch the Python client to use a client string of "API: Python"
to allow us to determine more easily which bindings our users are using.
(imported from commit 7216c3d150b371835f14d1bc8d81979a92e44925)
After this commit, we built an API tarball and sent it to
CUSTOMER4, and then promptly reverted the commit so that
we could continue as we had been before.
(imported from commit 662519a79edd508e7c115b451a7ec6fbdf1fc0a4)
To incorporate the site parsing fix from a couple weeks ago.
Before deploying this to prod we need to run build-api-tarball and
deploy the code to humbughq.com as for usual API releases.
(imported from commit f6711f5cc07d174c30866029032a595ecee785a3)
At Ksplice we used /usr/bin/python because we shipped dependencies as Debian /
Red Hat packages, which would be installed against the system Python. We were
also very careful to use only Python 2.3 features so that even old system
Python would still work.
None of that is true at Humbug. We expect users to install dependencies
themselves, so it's more likely that the Python in $PATH is correct. On OS X
in particular, it's common to have five broken Python installs and there's no
expectation that /usr/bin/python is the right one.
The files which aren't marked executable are not interesting to run as scripts,
so we just remove the line there. (In general it's common to have libraries
that can also be executed, to run test cases or whatever, but that's not the
case here.)
(imported from commit 437d4aee2c6e66601ad3334eefd50749cce2eca6)
We need to run build-api-tarball and release it on prod when pushing
this commit to prod.
(imported from commit 09e86500d2d208b1972c87444b4c2d56faafc8e6)
Before pushing this to prod, we need to build the 0.1.2 API tarball
and deploy it to the appropriate place on our servers.
(imported from commit ec1a07b3cc2a3e360dac32823ff7cd9de9de1da2)
Previously we were installing data files to e.g. /usr/local/example
and /usr/local/integrations, which is really not OK.
(imported from commit 0efb50412f93efabfe55443d5cac57a8ebb9fe06)
This works much better for working with staging, since rather than
needing to tell each individual tool that you're using staging, you
just specify that along with your API (which at the moment implies
whether you should be using staging or prod).
(imported from commit c1de8e72c24f35ef2160bce5339a5f03c6e1da95)
It doesn't matter for this script, but I worry the code will be
copy-pasted into other new plugins.
(imported from commit 0fe5280af5aa05a7efc3d146f1570f9a72c62027)
This should fix the symptoms of the problem we've been having where a
few API clients using the MIT Zephyr mirroring system sometimes seem
to end up with a too-old value of last.
(imported from commit 9f2426fa6a7e8365e8d3443bfd2cce3238cc9510)
I would prefer to be testing the attribute itself rather than the
version, but it's not easy to access without an actual request object,
and I'd prefer to compute this once-and-for-all on startup, rather
than on each request, since the latter just seems fragile.
(imported from commit dd74cadb1b2359faeb3e1b482faeee4003dfad77)
Bots are not part of what we distribute, so put them in the repo root.
We also updated some of the bots to use relative path names.
(imported from commit 0471d863450712fd0cdb651f39f32e9041df52ba)
My previous commit (fbdc092029bbafea716e27fbb99fec58a6f24392)
incorrectly specified that you must have a version of python-requests
greater than 0.12.1, when it should be a >= relation since 0.12.1 is
sufficient.
(imported from commit 9f716af6dfe0ce17d982fc22d507f144e9543bec)
Previously, if users of our code put the API folder in their pyshared
they would have to import it as "humbug.humbug". By moving Humbug's API
into a directory named "humbug" and moving the API into __init__, you
can just "import humbug".
(imported from commit 1d2654ae57f8ecbbfe76559de267ec4889708ee8)
The old-style api.humbug is deprecated, so we rewrite the path for things
to work correctly.
(imported from commit 360282b70fab1ad9d9d517157fc4fe06f9acd6a2)
This was causing about 10% of the time, personals being forwarded by
tabbott/extra@ATHENA.MIT.EDU to get this error:
zwrite: Field too long for buffer while sending notice to
tabbott/extra@ATHENA.MIT.EDU
We don't fully understand the cause of the problem, but this fixes it.
(imported from commit 22c39a1061cde9ad6973ef07aee7227623a3d47d)
Sometimes the very first message we send isn't received by
python-zephyr; this could be because of our growing a 17-message queue
of zephyrs to service, so let's not do that.
(imported from commit 281bf1807442b6335b05c803b1a47e0a162bef4e)
This ensures that Humbug receives the verbatim text of the Nagios
body, rather than a slightly modified version. Tested by running
manually.
(imported from commit 7e0eea0b230fd8c5552860acfb7372099598f036)
The refactoring that we did a couple weeks ago to make the zephyr
mirror script restart itself automatically (by splitting it into
zephyr_mirror.py and zephyr_mirror_backend.py) had a poor interaction
with our code for killing old zephyr_mirror processes (to prevent
double-mirroring). If you manually ran two copies of the outer
mirroring script (zephyr_mirror.py), then the second one would on
startup kill the first one's zephyr_mirror_backend.py children (for
being duplicate zephyr_mirror_backend.py processes that would result
in double-mirroring). However, importantly, it did not kill the first
mirroring script's zephyr_mirror.py parent process, so the first
mirroring script would then proceed to startup up new children. The
process then repeats, with the two scripts' roles reversed.
This issue didn't affect the sharded mirroring case, where I had been
doing the testing of the kill code with that refactoring, because we
don't have a version of the outer zephyr_mirror.py loop for that
situation (a consequence of it being hard to restart the threads
properly with the run_parallel API that we're using to spawn all the
children).
(imported from commit d4886ac77312a6b0ebd0d612f6fb084970bf23a2)
This is probably a lot more annoying to use, in that e.g. there are
separate log files for the two directions of the mirror, but we
haven't used these logs for much, so whatever.
(imported from commit d3bc407d90099214d242526c01cd3d3cd9d9d9bd)
Previously all that we logged was the sender, which turns out to be a
constant for humbug=>zephyr mirroring.
(imported from commit 527a3ac4b9b815a2b4d6b63c3ad92d9d5ad99a6e)
feedback-bot and zephyr_mirror will need to be updated and restarted
when this is deployed to prod.
(imported from commit fe2b524424c174bcb1b717a851a5d3815fda3f69)
Zev Benjamin
Luke Faraone
Leo Franchi
Waseem Daher
Jessica McKellar
Tim Abbott
Keegan McAllister
Reid Barton