Sun, Apr 21
Here are the statements:
Here are the creation statements for dev and production:
Sat, Apr 20
Since in either case we don't need to have special Varnish rules, I think we need both the query parameter and UA matching in order to ease the transition. The plan would be:
The simplification code has been deployed without issues, and we have populated the new table with dumps for en, de, fr, it, es, pt, pl, ja and ru wikipedias. The last step here is to delete the old, unused keyspaces.
Incident report available here.
Fri, Apr 19
Heh, no, it turns out we have forgotten to update the response profile version in the spec. PR #1122 is the fix.
This is likely a bug in Swagger-UI; there is probably a problem with the Accept header having quotes which are probably not escaped. I'll take a look.
Thu, Apr 18
Fix deployed, all looking good.
Still UBN, waiting on the mw-core side for this.
The immediate problem with jobs failing because of invalid titles has been addressed, so lowering the priority. Next step (which have to wait for the train to fully complete) include removing the title and namespace parameters from the job schema and not using them when enqueuing/dequeuing the jobs.
What we originally discussed was basically to leave databases outside of the realm of k8s. So MariaDB, Postgres, Cassandra and friends would still stay on bare metal. We have also touched upon the question of whether the services that directly access these storage engines would stay there or not, and we opted for keeping them as-are for now. In the first phase of the move to k8s we would move only stateless services, but I can see us moving those directly using storage too in a while. Whether the storage engines themselves would ever be moved if up for discussion, but IMHO that's not what containers are for.
Wed, Apr 17
@Pchelolo let's add it to ops/puppet?
Tue, Apr 16
Mon, Apr 15
+1, sounds like a plan!
+1 for SSDs. We will be directly exposing time-based messages to consumers, so I imagine random disk access will greatly increase in the mid-term.
Fri, Apr 12
The RESTBase part has been done long ago.
PR #1103 is the current work-in-progress patch for the back-end service's config.
Thu, Apr 11
Wed, Apr 10
+1. We should also find a way to evangelise it. Perhaps by doing a tech talk or something similar would do and/or present it at the relevant conferences and venues (Hackathon, Wikimania at least).
Given that overall proton has been (relatively) stable in the current config and that a plan to move it to k8s exists, I'll go ahead and resolve this.
Tue, Apr 9
Patch merged, will go out with today's train, resolving.