[14:07:32] jynus: How painful is https://phabricator.wikimedia.org/T111769 to you? [14:08:02] It seems we could drop the eu_touched field, but it would require a fair bit of work [14:08:32] as painful as probably blocking ROW-based replication [14:08:47] yiks [14:08:49] * yikes [14:08:55] what's the timeline for that? [14:09:07] I'm not sure its worth it, as apparently dependency tracking via Cassandra is on the way (which would replace) [14:09:38] "tracking via Cassandra is on the way" [14:09:54] That's what I've been told [14:10:09] no idea whether that's really the case or what the exact timeline is [14:10:15] ROW based replication will be applied in January 2016 according to the timeline [14:10:22] Daniel told me he things it's going to be there in the next six months [14:10:26] ugh [14:10:33] https://phabricator.wikimedia.org/T112637 [14:11:42] that is the plan, at least (3 months to apply changes at application side, on september) [14:12:16] hm... I just want to avoid having to massively alter it now [14:12:24] and then having to redo the whole thing anyway in May or so [14:12:51] See also https://phabricator.wikimedia.org/T124737 [14:14:52] ask for it [14:15:59] Probably need to do that, yeah [14:16:25] Might be time to set up restbase + cassandra for me … [14:16:31] I mean, file a ticket asking for the schema change [14:16:53] dropping eu_touched, you mean? [14:17:02] whatever is needed [14:17:28] That would require altering the code first... then seeing whether that flies in production... if it does, we can alter the table [14:17:44] After my analysis, I don't think it'll be that much work on Wikibase [14:17:55] doable in an Afternoon (excluding CR) [14:19:22] create a proof of concept on beta if you are unsure [14:22:11] I need to have a few conversations before spending time on this… but I'll see to get this done. [14:22:30] You might want to adjust the priorities of the tasks to actually be accurate [14:22:44] if it's just "normal" we could as well just wait another 6 months for it [14:28:33] please, add me on the ticket, ask me for help explicitly, I am busy with other production issues right now [14:30:04] I don't need help right now… I "just" need to know how severe the problem is and whether we should tackle it right now [14:30:09] Well, I need help deciding that [14:30:21] and also need to make the case for others in my team [14:31:58] to give you an idea of my personal point of view: I think wikidata updates are the worse mediawiki-realted production cluster problem happening right now [14:32:39] far more than API slowness [14:33:33] Ok… I feared that would be the case. Can you note that on https://phabricator.wikimedia.org/T111769 or on https://phabricator.wikimedia.org/T124737 in one way or another? [14:33:33] not that ticket only, I am including there general maintenance [14:33:49] Yeah, I guess… we have some pretty bad things going on [14:34:13] wb_terms is also a single big nightmare [14:39:43] I am not the only one bblack, ori have also some "near-crashing varnish infrastructure" concerns [14:39:56] varnish and queue [14:40:11] I know… I'm trying to put that on the plate for quite some time now [14:40:25] I think we at least have a meeting over it now [14:40:31] hey, you asked for a honest opinion :-) [14:40:50] everithing is cool, and I thank you for trying to be active about it [14:41:25] I don't want to discourage you from being honest and direct… it's what works best [14:41:42] Otherwise these things just lay around until they actual get urgent two years later [14:41:51] that's my experience [14:42:21] I mentioned several times- I do not think this is a "wikidata" issue, it is just that it is very young compared to the rest of mediawiki, but at the same time ambitious (touching many things), which makes it difficult [14:43:22] We're moving fast… and we did some rather poor choices in the past (which is perfectly normal), but obviously leads to such problems [14:44:27] the question here is- do not be afraid of making schema changes [14:44:41] I make a lot of fuss about them [14:44:53] but that is no problem compared to having a good design [14:45:07] *never* compromise [14:45:09] ok? [14:45:30] That's a good position, thanks [14:46:22] how many complaints did you get from last schema change? Even if it didn't go perfectly? [14:46:34] Virtually none [14:46:41] so that's it [14:46:54] there was more fuss from people that blamed it for stuff that broke unrelated than actual complaints [14:47:11] yep, session stuff and that [14:47:39] so that goes my phyilosophy [14:48:15] If you want to explore some innovative solution with Cassandra? yes, ok, explore, but do not understimage time for new design vs. maintenance [14:48:25] *underestimage [14:48:31] *underestimate