Change propagation

Change propagation is distributing changes between services, using the EventBus infrastructure. Its rules subscribe to specific topics in eventbus, and execute an action (typically a templated HTTP request, or a CDN purge) in response to each event. The most up-to-date documentation on the change propagation service can be found on Wikitech

Tutorials for the most common use-cases

When a new rule configuration is created, you should follow the process to include the rule:

Create a Gerrit patch to review for the config.example.wikimedia.yaml file in the change-propagation repository on Gerrit. Tips:
- Use publicly available URIs if that's possible.
- Good to create a unit test.
- Configure retry policy and error ignoring
Wait for the services team to review.
When a pull request is merged, create the same change in Gerrit for the puppet config file. The puppet config change might be different from your PR in the GitHub repo since it needs to include some templating for the service hosts. Reviewers list should include a person from the services team and at least one person from the operations team.
After puppet is merged and deployed ask the services team to restart change propagation service so that it pick up the new config.

Checking what templates are being processed now

The highest load generated by the ChangeProp service is derived from template expansion - all pages transcluding a certain template should be rerendered after the template was edited. To check which large templates are being processed right now got to kafka1001.eqiad.wmnet and run a /home/ppchelko/check_templates.sh script. The script will output all the templates that are being processed right now or are in the backlog. Please note, that having duplicates in the output is OK - change-prop processor is concurrent and it commits the smallest processed offset, so the output of the script contains not only the templates that are in the backlog, but also the templates that have already been processed but not yet committed.