{{Fixme|1=This information is out of date - we do not deploy or manage restbase using Ansible}}
{{Fixme|1=This document needs expansion}}
[[mw:RESTBase|RESTBase]] is an API proxy serving the REST API at <code>/api/rest_v1/</code>. It uses Cassandra as a storage backend.
[[mw:RESTBase|RESTBase]] is an API proxy serving the REST API at <code>/api/rest_v1/</code>. It uses Cassandra as a storage backend.
It is currently running on restbase100{1..9}.eqiad.wmnet, and shares the hardware with Cassandra instances.
It is currently running on hosts with the <code>profile::restbase</code> class.
== Deployment and config changes ==
== Deployment and config changes ==
=== Getting the Ansible deploy scripts ===
RESTBase is deployed by [[Scap]].
We are using a set of simple [https://github.com/wikimedia/ansible-deploy.git Ansible deploy scripts] to coordinate rolling deploys and restarts. These are currently not installed on a deploy host (FIXME!), so you need to check them out locally:
The scripts assume that you have a working SSH proxy command setup, so that <code>ssh restbase1001.eqiad</code> works. The following ansible commands are assumed to be executed from within the ansible-deploy checkout (so <code>cd ansible-deploy</code>).
=== Preparing the deploy repository ===
RESTBase is a service-runner based application, to prepare the software repository for deploy, follow the instructions on updating, [[mediawikiwiki:ServiceTemplateNode/Deployment|here]].
=== Deploying to staging ===
Before deploying to production, we generally deploy to the staging cluster (xenon, praseodymium and cerium) first. We deploy via Ansible, which handles the full rolling deploy, including restarts and checks.
In your local copy of the [https://github.com/wikimedia/ansible-deploy.git ansible-deploy] tree, edit <code>group_vars/restbase-staging</code>, and set <code>restbase_version</code> to the SHA1 sum of the [[#Preparing_the_deploy_repository|deploy repository]] HEAD, and run <code>ansible-playbook -i staging -e target=restbase roles/restbase/deploy.yml</code>
Tip: It is common to first deploy to a "canary node", and evaluate the impact there before proceeding. To limit the deploy to some subset of hosts, use the <code>-l</code> argument: i.e. <code>ansible-playbook -i staging <code>-e target=restbase</code>-l xenon.* roles/restbase/deploy.yml</code>. Regular expressions are also supported, which is especially useful for numbered hosts in production: <code>-l ~restbase100[1-2].*</code>.
=== Deploying to production ===
If things went well in staging, then you can proceed to deploy to production.
In your local copy of the [https://github.com/wikimedia/ansible-deploy.git ansible-deploy] tree, edit <code>group_vars/restbase-production</code>, and set <code>restbase_version</code> to the SHA1 sum of the [[#Preparing_the_deploy_repository|deploy repository]] HEAD, then <code>ansible-playbook -i production <code>-e target=restbase</code> roles/restbase/deploy.yml</code>
Tip: It is common to first deploy to a "canary node", and evaluate the impact there before proceeding. To limit the deploy to some subset of hosts, use the <code>-l</code> argument: i.e. <code>ansible-playbook -i production <code>-e target=restbase</code>-l xenon.* roles/restbase/deploy.yml</code>. Regular expressions are also supported, which is especially useful for numbered hosts in production: <code>-l ~restbase100[1-2].*</code>.
=== Rolling back a deploy ===
Modify <code>restbase_version</code> in <code>group_vars/restbase-{production,staging}</code> from the revision deployed, to the revision you'd like to roll back to. Then, deploy as usual: <code>ansible-playbook -i production <code>-e target=restbase</code>roles/restbase/deploy.yml</code>
=== Performing a rolling restart ===
From an ansible tree: <code>ansible-playbook -i production <code>-e target=restbase</code> roles/restbase/restart.yml</code>
''Substitute the value given for <code>-i</code> as necessary.''
=== Doing Dry Runs ===
Each of the <code>ansible-playbook</code> commands above can be invoked with the <code>--check</code> and <code>--diff</code> flags to get an indication of what the effect will be, without actually making any changes.
=== Deploy configuration changes ===
As config changes can trigger database changes in RESTBase, it is [[Incident_documentation/20150519-RESTBase|very important]] that those are deployed in a rolling fashion as well. The configuration templating is handled by puppet, which doesn't directly support rolling deploys. To work around this, we need to manually perform a rolling deploy by disabling puppet & then re-enabling it one by one. Procedure (note: all of the following commands need to be run as root):
* Disable puppet on all restbase* hosts, to make sure that config changes are applied one host at a time: <code>puppet agent --disable</code>
Consider making an edit to a page using Visual Editor.
Take a look at some recent Visual Editor-performed changes (French Wikipedia works great for this, as they use VE by default). Do the diffs looks reasonable?
Keep a close eye on #wikimedia-operations, if someone spots a problem, they're likely to raise the issue there.
Other considerations
Be sure to log all actions ahead of time in #wikimedia-operations. Don't be shy about including details.
Debugging
To temporarily switch to local logging for debugging, you can change the config.yaml log stanza like this:
logging:
name: restbase
streams:
# level can be trace, debug, info, warn, error
- level: info
path: /tmp/debug.log
Alternatively, you can log to stdout by commenting out the streams sub-object. This is useful for debugging startup failures like this: