Page MenuHomePhabricator

Integrate eventbus-based event production into MediaWiki
Closed, ResolvedPublic

Description

Problem

As part of the Services team's goal to implement change propagation, we have the requirement that MediaWiki emit events to the eventbus, for the following edit-related events:

  • article creation
  • article deletion
  • article undeletion
  • article edit
  • article rename
  • revision deletion (suppression)
  • file upload

A first set of event schemas documenting the required properties is currently under discussion at https://github.com/wikimedia/restevent/pull/5.

Reliability

These events will be used for important tasks like hiding deleted revisions, invalidating caches, and replicating changes across datacenters. For this reason, event production needs to be reliable and timely. Best-effort mechanisms like UDP are unlikely to provide the required level of reliability.

To ensure a complete event history in the face of errors, MediaWiki should log event production failures in a way that enables an automatic retry at a later time. Duplicate event submissions will be recognized based on the supplied event ID, a v1 UUID. The producer implementation should also set reasonable timeouts to minimize the impact of failures on the overall MediaWiki request processing.

Solutions

We can deal with it in two ways:

  1. Create an extension that will wait for the appropriate hooks to fire
  2. Integrate event emission in MW-Core

Given that the list of events is currently rather restricted, we could opt for option (1). However, the drawback is the creation of yet another extension that fires off events. Moreover, as the number of tracked events grows, the extension is bound to become quite larger. Additionally, relying on hooks means being compliant and in sync with their API.

Ideally, we'd like to go with option (2). Event creation and emission can be controlled via configuration settings (in LocalSettings.php) and easily turned on/off. Also, putting this into core would mean better code review and greater visibility, which is of utmost importance for events shared within MW event consumers.

See also

Details

SubjectRepoBranchLines +/-
operations/mediawiki-configmaster+5 -4
operations/mediawiki-configmaster+1 -0
operations/mediawiki-configmaster+2 -0
operations/mediawiki-configmaster+11 -0
mediawiki/corewmf/1.27.0-wmf.9+5 -0
mediawiki/coremaster+4 -0
mediawiki/corewmf/1.27.0-wmf.10+4 -0
mediawiki/tools/releasemaster+1 -0
mediawiki/extensions/EventBusmaster+1 -1
mediawiki/extensions/EventBusmaster+35 -26
mediawiki/extensions/EventBusmaster+8 -1
mediawiki/extensions/EventBusmaster+4 -2
mediawiki/coremaster+14 -2
operations/mediawiki-configmaster+1 -0
mediawiki/extensions/EventBusmaster+17 -8
operations/mediawiki-configmaster+10 -0
mediawiki/extensions/EventBusmaster+1 -1
mediawiki/vendormaster+2 K -13
mediawiki/extensions/EventBusmaster+841 -0
mediawiki/coremaster+170 -0
mediawiki/coremaster+165 -0
operations/mediawiki-configmaster+186 -0
Show related patches Customize query in gerrit

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Eevans, we were considering including the topic in the envelope portion of the event before. One potential benefit of going that way would be support for mixed-topic batch submissions. Downsides are the usual batch issues of error handling for partial failures, and possibly cost. However, I think in this case the cost should be negligible & can be effectively controlled by limiting the POST size.

@mobrovac, @Pchelolo, @Ottomata: Any thoughts on this?

I do wonder though whether RCFeed is the best fit for something fairly specific like this. My impression was that EventRelayer might be a bit more geared towards accepting structured data rather than a blob, and it seems unlikely that we'd want to use any of the existing RCFeed backends for EventBus events.

+1 to including topic in the event meta data. This makes EventLogging code cleaner, as the streams abstraction only allows me to pass on the event object to each writer. Having the topic in the event means the kafka writer can produce to the proper topic while only having the event data.

Agree about batch producing (cool!) and difficulties of partial failures (meh). I haven't been worrying about batch producing in via the http endpoint for the MVP, but ja, having the topic in the event would make this possible.

I added a note about including the topic on the spec PR.

I do wonder though whether RCFeed is the best fit for something fairly specific like this. My impression was that EventRelayer might be a bit more geared towards accepting structured data rather than a blob, and it seems unlikely that we'd want to use any of the existing RCFeed backends for EventBus events.

So there is this issue (getting at topic). Additionally, I've also run across another, namely that if the events we are interested in are a subset of all possible changes, then we need to be able to filter (i.e. not produce for uninteresting changes).

Both of these issues come about as a consequence of the interfaces being designed for the formatting and delivery of text payloads.

Both can be worked around though. As mentioned before, we could include the topic in each event and alter the service API accordingly (and this idea has some merit outside of this work-around). And, we can return null from the formatter, and skip delivery when so-signaled in the engine (this feels a little icky).

As interfaces go, EventRelayer does seem like a better fit (a single object with a method that is passed structured data), but unlike RCFeed, it is (I think) missing the needed integration. I assume that we'd need to teach some MW subsystem to pass events to a relayer implementation similar to the way that wan object cache does now. Input from someone more familiar with MW internals with guidance on this would be much appreciated.

We could also consider fixing the RCFeed interfaces. I don't think there is any way to do this without it being a breaking change, but @Legoktm has suggested that maybe that's OK. We might even be able to leverage EventRelayer for this. Maybe use it as the interface for feed implementations. Again, input from those more familiar with MediaWiki would be most welcome!

As mentioned before, we could include the topic in each event and alter the service API accordingly (and this idea has some merit outside of this work-around).

FYI, I did this in EL service today. (Can change back if we need to.)

@Eevans, afaik we'll need to set up hooks where we need them in any case. We can either register for existing MW hooks (as the RESTBaseUpdateExtension does), or add specific hooks we need.

Change 252950 had a related patch set uploaded (by Eevans):
[WIP] RCFeed-based event production

https://gerrit.wikimedia.org/r/252950

I might be wrong, but given the number of suggestions I've received for possible ways of approaching this (EventLogging, WikimediaEvents, Monolog, EventRelayer, RestbaseUpdateJobs), there would seem to be an unhealthy proliferation of event propagation mechanisms in MW. If this is the case, I'd rather spend the time on something that could be used to consolidate, rather than contribute to the problem.

RCFeed still seems like a reasonable way of doing this, provided a breaking change is acceptable. Combining the formatter/engine interfaces into a single one that accepts structured data seems like a good approach. EventRelayer fits this criteria, and is already there. A ColourfulIRCEventRelayer and RedisPubSubEventRelayer could replace the existing engine/formatter implementations in use.

@Legoktm, @Krinkle, @aaron: Thoughts on this?

In the meantime, I've put up a WIP implementation that uses the existing interfaces. Given the increasingly tight timeline for the quarterly goals, it'd be nice to have as a fallback at least.

We had lots of follow-up discussion on IRC:
https://gist.github.com/gwicke/df8b347058a19e6556f6

The gist of it is that basically all the information we need is already available in the log table, but only most of it in RCFeed. Because of this, it seems to be make sense to find a way to hook into the log path.

Hm, something to also consider, especially if this data is mostly being written to MySQL in a useable format:

https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor
http://maxwells-daemon.io/

We had lots of follow-up discussion on IRC:
https://gist.github.com/gwicke/df8b347058a19e6556f6

The gist of it is that basically all the information we need is already available in the log table, but only most of it in RCFeed. Because of this, it seems to be make sense to find a way to hook into the log path.

After looking, I don't think this is true (that there is a single table that is the source of truth). I'd be very happy to be proven wrong though, so pointers welcome!

Summarizing a conversation on IRC w/ @aaron, another option would be to use hooks, in particular one based on his proposed PageChanged.

@Eevans, hooks will certainly work. See the link in the task description to the RESTBase extension.

Using hooks would be the most straightforward and quickest way of achieving this, but do we really want to replace one extension with another?

Change 253799 had a related patch set uploaded (by Eevans):
[WIP] hooks-based event production

https://gerrit.wikimedia.org/r/253799

Given the mid-December cutoff for deployments, getting some sort of event production into MediaWiki in time to make this quarter's goal is looking more and more at risk. I am still very much interested in doing this Right, but would like to simultaneously pursue a more temporary, stop-gap solution while we work on figuring out what Right should look like.

To this end (and mostly as a strawman at this point), I have posted: https://gerrit.wikimedia.org/r/#/c/253799

Comments on this would be very welcome!

IMO, the safest way to do this (for data integrity) would be having an OAI-style table on the main DBs that includes change information for all desired events and is committed in the same transaction. You could have a set of servers that just poll the events in chunks and dump them into EventBus directly. They would ideally want some way of seeing the highest event in Kafka (and corresponding monotonic DB ID) to know what to read/push from DB=>Kafka next. For getting both more HA and staying FIFO one could imagine 2+ daemons that try to do this, but with only one winning via GET_LOCK() for any given batch (I'm sure one daemon could keep up with this, so partition seems out of scope).

I don't agree with this implementation idea: you're basically using the database as a queue to reliably input data... in a queue.

I know that having the event queue be separated from the database creates a gap that can lead to inconsistencies if the queue fails when the db doesn't - and that's why we need the queue to be extremely reliable.

In case of inconsistencies, though, what would be useful is to have all changes that happen due to an event to keep an easy-to-find reference to that change, so that it's easy to debug any case in which a dependent system is out of sync. But we can still require in kafka that any message has been reliably delivered to the consumer(s) before removing it.

Finally, for simple connection errors or other failures from mediawiki in submitting the events to the queue, we could manage the error and log the event clearly.

Change 254033 had a related patch set uploaded (by Eevans):
[WIP] hooks-based event production

https://gerrit.wikimedia.org/r/254033

To summarize a meeting from earlier today with @Ottomata, @Legoktm, @Krinkle, and @aaron:

  • There is still no consensus on the best way to produce events, (more research is needed)
  • The timeline however is getting very short, if we are to make our quarterly goals, we'll need to prioritize a shorter-term, temporary solution.
  • We will move forward with a temporary solution using hooks, implemented out of operations/mediawiki-core (WIP changeset here).

Change 254086 had a related patch set uploaded (by Eevans):
[WIP] hooks-based event production extension

https://gerrit.wikimedia.org/r/254086

Change 254033 abandoned by Eevans:
[WIP] hooks-based event production

Reason:
Moved to an extension (https://gerrit.wikimedia.org/r/#/c/254086/)

https://gerrit.wikimedia.org/r/254033

[ ... ]

Scratch that, let's do an extension instead!

Change 252950 abandoned by Eevans:
[WIP] RCFeed-based event production

Reason:
Abandoning in favor of an extension (https://gerrit.wikimedia.org/r/#/c/254086/)

https://gerrit.wikimedia.org/r/252950

Current status:

Work on the extension is progressing; To the extent that the various events themselves are implemented, it is sending events in my test environment to the eventlogging service.

Outstanding issues:

  • We need to determine the various URIs to use for the meta.uri attribute, and update the extension accordingly.
  • The meta.id attribute is currently using a type 4 UUID, not a type 1. I don't believe MW has any anything for generating type 1 UUIDs, so code for that will need to be found/written.
  • The meta.request_id currently contains a generated type 4 UUID, and instead should be populated with the value from the x-request-id request header, if present.
  • The "visibility set" event is just a stub and needs to be completed
    • And, the hook for this doesn't seem to pass all the requisite information, so some work here may be needed as well
  • If possible/reasonable, the HTTP POST should be made a deferred task
  • Docs need writing
  • Testing, testing, testing

Pending final review, the EventBus extension should be ready to move to deployment-prep; The MVP features are complete.

https://gerrit.wikimedia.org/r/#/c/254086/

Change 253799 abandoned by Eevans:
[WIP] hooks-based event production

Reason:
Abandoning in favor of an extension (https://gerrit.wikimedia.org/r/#/c/254086/)

https://gerrit.wikimedia.org/r/253799

Change 256418 had a related patch set uploaded (by Eevans):
[WIP] setup EventBus extension for deployment-prep

https://gerrit.wikimedia.org/r/256418

Change 256575 had a related patch set uploaded (by Eevans):
[WIP] add ramsey/uuid, needed by mediawiki/extension/EventBus

https://gerrit.wikimedia.org/r/256575

If I have it right, the steps remaining to have the EventBus extension moved to deployment-prep are:

Any feedback on this would be appreciated, the timeline is getting quite short, and if I keep discovering new steps then we'll never make it in time. :)

I'd also like to suggest, that if the security review is going to take more than a day or two to complete, that we eliminate the dependency on ramsey/uuid by generating a type 4 UUID for meta.id, at least temporarily (there is a separate ISO8601 timestamp we can use). Thoughts on this?

If I have it right, the steps remaining to have the EventBus extension moved to deployment-prep are:

If you omitted the step of deploying it in prod on purpose, then yes, that sounds about right :)

I'd also like to suggest, that if the security review is going to take more than a day or two to complete, that we eliminate the dependency on ramsey/uuid by generating a type 4 UUID for meta.id, at least temporarily (there is a separate ISO8601 timestamp we can use). Thoughts on this?

meta.id will be primarily used for event de-duplication in the change-propagation system. However, that is not part of the MVP, so I'd be ok with doing this for the time being. This way we could decouple deploying the extension from the overhead induced by the UUID lib dependency, and let that process run its natural course in parallel. Upon its completion, getting the dependency back into the extension is rather trivial.

If I have it right, the steps remaining to have the EventBus extension moved to deployment-prep are:

If you omitted the step of deploying it in prod on purpose, then yes, that sounds about right :)

I did (omit it on purpose), focusing on deployment-prep in this context as it's the next milestone (and one that is targeted at this week).

@mobrovac or are you concerned there are other surprises lurking beyond this horizon? Is the move from deployment-prep to production something more than a variation on https://gerrit.wikimedia.org/r/#/c/256418?

@mobrovac or are you concerned there are other surprises lurking beyond this horizon? Is the move from deployment-prep to production something more than a variation on https://gerrit.wikimedia.org/r/#/c/256418?

It needs to be scheduled on the deploy train at least a week in advance, AFAIK, which means we'd need to do so next week the latest.

To be on the safe side, let's ask @greg. @greg, for context, we want to deploy a new MW extension which would emit events to the Event-Platform system we are building. We want to do so right before the deployment freeze. Other than scheduling it, are there other considerations we should include in this process?

My usual response is:

  1. Has the new extension been security reviewed?
  2. Has it been deployed to Beta Cluster and tested there?

If yes to both, then it's simply a matter of scheduling when you want it to be deployed to production (and ideally, who you want to do the actual deploy).

Cheers @greg for the pointers!

  1. Has the new extension been security reviewed?

Seeking input in T120212: Security review of EventBus extension.

  1. Has it been deployed to Beta Cluster and tested there?

Likely to happen in the next day or two.

If yes to both, then it's simply a matter of scheduling when you want it to be deployed to production (and ideally, who you want to do the actual deploy).

Ok, perfect!

Change 254086 merged by Mobrovac:
hooks-based event production extension

https://gerrit.wikimedia.org/r/254086

Change 256575 abandoned by Eevans:
[WIP] add ramsey/uuid, needed by mediawiki/extension/EventBus

Reason:
With UUID v1 support now in core (https://gerrit.wikimedia.org/r/#/c/56567), this is no longer needed.

https://gerrit.wikimedia.org/r/256575

Change 257370 had a related patch set uploaded (by Eevans):
use v1 UUID for meta.id attribute

https://gerrit.wikimedia.org/r/257370

Change 257420 had a related patch set uploaded (by Eevans):
execute HTTP POST as a deferred task

https://gerrit.wikimedia.org/r/257420

Change 257370 merged by jenkins-bot:
use v1 UUID for meta.id attribute

https://gerrit.wikimedia.org/r/257370

Change 256418 merged by jenkins-bot:
setup EventBus extension for deployment-prep

https://gerrit.wikimedia.org/r/256418

Change 257493 had a related patch set uploaded (by Eevans):
request timeout config

https://gerrit.wikimedia.org/r/257493

Change 258475 had a related patch set uploaded (by Eevans):
handle parent_revision_id on page creation

https://gerrit.wikimedia.org/r/258475

Change 257493 merged by jenkins-bot:
request timeout config

https://gerrit.wikimedia.org/r/257493

Change 259156 had a related patch set uploaded (by Eevans):
enable EventBus logging channel (currently only in beta)

https://gerrit.wikimedia.org/r/259156

Change 259156 merged by jenkins-bot:
enable EventBus logging channel (currently only in beta)

https://gerrit.wikimedia.org/r/259156

Change 259604 had a related patch set uploaded (by Eevans):
Pass created revision to TitleMoveComplete hook

https://gerrit.wikimedia.org/r/259604

Change 259604 merged by jenkins-bot:
Pass created revision to TitleMoveComplete hook

https://gerrit.wikimedia.org/r/259604

Change 259628 had a related patch set uploaded (by Eevans):
Use Revision hook argument

https://gerrit.wikimedia.org/r/259628

Change 259628 merged by jenkins-bot:
Use Revision hook argument

https://gerrit.wikimedia.org/r/259628

Change 259790 had a related patch set uploaded (by Eevans):
Leverage revision object for parent

https://gerrit.wikimedia.org/r/259790

Change 258475 merged by jenkins-bot:
handle parent_revision_id on page creation

https://gerrit.wikimedia.org/r/258475

With the merging of https://gerrit.wikimedia.org/r/258475, the last remaining (known) functional issues have been sorted out; Here is the results of some (manual) testing in beta:

Creating C4e607b:

kafka console-consumer --topic mediawiki.page_edit --from-beginning
{"meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:31:49+00:00", "id": "b7ad74cb-a808-11e5-aedc-fa163ed2729a", "request_id": "d60514b1-7fa0-4ac9-a1b7-25cddd8feb4a", "schema_uri": "page_edit/1", "topic": "mediawiki.page_edit", "uri": "/edit/uri"}, "namespace": 0, "page_id": 151483, "revision_id": 299160, "save_dt": "2015-12-21T17:31:49Z", "summary": "created.", "title": "C4e607b", "user_id": 8941, "user_text": "Eevans"}

Editing C4e607b:

kafka console-consumer --topic mediawiki.page_edit --from-beginning
{"meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:33:10+00:00", "id": "e79ae55b-a808-11e5-aedc-fa163ed2729a", "request_id": "2513ff65-e7ba-448d-ab12-c3e0ff561110", "schema_uri": "page_edit/1", "topic": "mediawiki.page_edit", "uri": "/edit/uri"}, "namespace": 0, "page_id": 151483, "parent_revision_id": 299160, "revision_id": 299161, "save_dt": "2015-12-21T17:33:10Z", "summary": "edited.", "title": "C4e607b", "user_id": 8941, "user_text": "Eevans"}

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=C4e607b_1&type=revision&diff=299161&oldid=299160

Deleting C4e607b:

kafka console-consumer --topic mediawiki.page_delete --from-beginning
{"meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:34:14+00:00", "id": "0e129cfb-a809-11e5-aedc-fa163ed2729a", "request_id": "b2dc696e-b3e7-4725-9837-3c4e463e0461", "schema_uri": "page_delete/1", "topic": "mediawiki.page_delete", "uri": "/delete/uri"}, "page_id": 151483, "summary": "Test delete.", "title": "C4e607b", "user_id": 8941, "user_text": "Eevans"}

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special%3ALog&type=delete&user=&page=C4e607b&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_tag_log=1&hide_review_log=1&hide_thanks_log=1

Restoring C4e607b:

kafka console-consumer --topic mediawiki.page_restore --from-beginning
{"meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:35:22+00:00", "id": "365ca4a2-a809-11e5-92ed-fa163e26265e", "request_id": "88aecdc6-c3d1-43a2-b1c0-b13acb5d90d6", "schema_uri": "page_restore/1", "topic": "mediawiki.page_restore", "uri": "/restore/uri"}, "namespace": 0, "new_page_id": 151484, "old_page_id": 151483, "summary": "Test restore.", "title": "C4e607b", "user_id": 8941, "user_text": "Eevans"}

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special%3ALog&type=delete&user=&page=C4e607b&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_tag_log=1&hide_review_log=1&hide_thanks_log=1

Moving C4e607b to C4e607b_1:

kafka console-consumer --topic mediawiki.page_move --from-beginning
{"meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:37:09+00:00", "id": "766d8c6b-a809-11e5-aedc-fa163ed2729a", "request_id": "bd230ae0-6320-4cd8-9c8e-545d0b5e543f", "schema_uri": "page_move/1", "topic": "mediawiki.page_move", "uri": "/move/uri"}, "new_revision_id": 299162, "new_title": "C4e607b 1", "old_revision_id": 299161, "old_title": "C4e607b", "page_id": 151484, "summary": "Test move.", "user_id": 8941, "user_text": "Eevans"}

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=C4e607b_1&type=revision&diff=299162&oldid=299161

Setting revision visibility attributes

kafka console-consumer --topic mediawiki.revision_visibility_set --from-beginning
{"hidden": {"comment": false, "sha1": false, "text": false, "user": false}, "meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:38:57+00:00", "id": "b6c2f84b-a809-11e5-aedc-fa163ed2729a", "request_id": "9ac8d211-e2bf-42c4-ab92-04da39c3dddd", "schema_uri": "revision_visibility_set/1", "topic": "mediawiki.revision_visibility_set", "uri": "/visibility_set/uri"}, "revision_id": 299161, "user_id": 8941, "user_text": "Eevans"}

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:RevisionDelete&target=C4e607b+1&type=revision&ids=299161

Unsetting revision visibility attributes

kafka console-consumer --topic mediawiki.revision_visibility_set --from-beginning
{"hidden": {"comment": true, "sha1": true, "text": true, "user": true}, "meta": {"domain": "en.wikipedia.beta.wmflabs.org", "dt": "2015-12-21T17:40:07+00:00", "id": "e043aa2b-a809-11e5-aedc-fa163ed2729a", "request_id": "1d3e1764-3063-43fa-be26-5dbf88a2f352", "schema_uri": "revision_visibility_set/1", "topic": "mediawiki.revision_visibility_set", "uri": "/visibility_set/uri"}, "revision_id": 299161, "user_id": 8941, "user_text": "Eevans"}

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:RevisionDelete&target=C4e607b+1&type=revision&ids=299161

Change 257420 merged by jenkins-bot:
execute HTTP POST as a deferred task

https://gerrit.wikimedia.org/r/257420

Change 259790 merged by jenkins-bot:
Leverage revision object for parent

https://gerrit.wikimedia.org/r/259790

Change 263777 had a related patch set uploaded (by Eevans):
add EventBus extension

https://gerrit.wikimedia.org/r/263777

Change 263787 had a related patch set uploaded (by Eevans):
add EventBus extension

https://gerrit.wikimedia.org/r/263787

Change 263797 had a related patch set uploaded (by Eevans):
EventBus configuration (currently disabled)

https://gerrit.wikimedia.org/r/263797

Change 263777 merged by jenkins-bot:
add EventBus extension

https://gerrit.wikimedia.org/r/263777

Change 263797 merged by jenkins-bot:
EventBus configuration (currently disabled)

https://gerrit.wikimedia.org/r/263797

Change 263787 merged by jenkins-bot:
add EventBus extension

https://gerrit.wikimedia.org/r/263787

Change 265107 had a related patch set uploaded (by Dduvall):
add EventBus extension

https://gerrit.wikimedia.org/r/265107

Change 265107 abandoned by Dduvall:
add EventBus extension

https://gerrit.wikimedia.org/r/265107

Change 265109 had a related patch set uploaded (by Dduvall):
add EventBus extension

https://gerrit.wikimedia.org/r/265109

Change 265142 had a related patch set uploaded (by Eevans):
Enable EventBus extension (post-deploy)

https://gerrit.wikimedia.org/r/265142

Change 265142 merged by jenkins-bot:
Enable EventBus extension on test wikis

https://gerrit.wikimedia.org/r/265142

The extension has now been enabled on testwiki and test2wiki. I've tested all of the currently supported actions (via testwiki), and the resulting events (as consumed from kafka1001.eqiad.wmnet) all look good.

Change 265553 had a related patch set uploaded (by Eevans):
enable EventBus extension on mediawikiwiki

https://gerrit.wikimedia.org/r/265553

Change 265553 merged by jenkins-bot:
enable EventBus extension on mediawikiwiki

https://gerrit.wikimedia.org/r/265553

The extension has now been enabled on mediwikiwiki. Incoming events are observable from kafka1001.eqiad.wmnet, and there are no errors reported in logstash.

Change 266564 had a related patch set uploaded (by Eevans):
Enable EventBus on remaining (applicable) wikis

https://gerrit.wikimedia.org/r/266564

Change 266564 merged by jenkins-bot:
Enable EventBus on remaining (applicable) wikis

https://gerrit.wikimedia.org/r/266564

The extension is now deployed to all (relevant) wikis, and is currently sending events at a rate of ~20/second, and there are no errors in logstash.

The only remaining blocker is T120212 (Security review of EventBus extension).

mobrovac removed a project: Patch-For-Review.
mobrovac removed a subscriber: gerritbot.