Fri, Jan 18
Thu, Jan 17
@Krinkle did mention he saw a couple fatal errors that looked worrisome, so I'd wait for him to comment before backporting the beta feature and announcing it.
Very good point @Mainframe98 - in fact I was planning to write an email to wikitech-l once the beta feature is set up and I have the green light from everyone involved in the project before activating it.
Wed, Jan 16
Do not use alpine as a base for your containers if you want to execute them in production. That is strictly limited to debian-based images, for which we can create a reliable upgrade pipeline. Also, we don't want a distro proliferation in production.
Tue, Jan 15
Might I suggest that you use a SRV dns record instead? It's more appropriate for enumerating members in a cluster. We use those for etcd discovery.
Sorry, I need some more specifics:
@Jhernandez I'm happy to explain to you whatever you might want to know about our load-balancing infrastructure, and how it interacts with proton.
Moving (even part of) the presentation layer outside of MediaWiki raises quite a few questions we have to make important decisions about.
Fri, Jan 11
I did some *very* lame benchmarking of the response of the banner url for elasticsearch (/), with the following code:
Thu, Jan 10
I think the current version of the RfC is reasonably well structured, to the point I think we should move the discussion here.
Another detail I kinda assumed was a given, but it's better to reiterate it:
Please note that the statement
php7.2-xdebug is now available in our repository:
Wed, Jan 9
This change is still not ready to ship sadly, I need to fix the logic as we should:
Tue, Jan 8
I think I have a decent idea of how to implement a basic version of what we want via nginx. I'll work on it this week hopefully.
FTR, I tried to save that page with php7 and failed as well. So I doubt this has to do with HHVM itself.
Fri, Jan 4
Thu, Jan 3
Incorporated @thcipriani's comments
Thanks for the comments @thcipriani, amending now. See my comments inline.
@Dzahn yup it's unused and useless as things stand, we should remove it.
Wed, Jan 2
I frankly have no idea why these unit test issues pop up; I'm pretty sure I didn't touch anything remotely related.
We decided to use a different approach for this patch, containing it in puppet rather than here.
Dec 21 2018
Also, if we're going to build microservices, I'd like to not see applications that "grow", at least in terms of what they can do. A microservice should do one thing and do it well. In this case, it's using data from mediawiki to render an HTML fragment; unless you want to make it do something different, the thing that might change is what data it needs to use.
Let me state it again: the SSR service should not need to call the mediawiki api. It should accept all the information needed to render the termbox in the call from mediawiki.
Dec 19 2018
Looking at live data, we have at least one shard that's doing evictions (150k of them) and all shards have 10M+ expired keys.
Dec 18 2018
Well that discussion was limited to Session storage, and I stand by the idea that service, and its datastore, shouldn't be concerned with anything else than sessions, unless we come to a further agreement.
Also: it is stated in https://wikitech.wikimedia.org/wiki/WMDE/Wikidata/SSR_Service that "In case of no configured server-side rendering service or a malfunctioning of it, the client-side code will act as a fallback". This is a bit the other way around with respect to what is usually done with workers, but I see two advantages from our point of view:
Looking at the attached diagrams, it seems that the flow of a request is as follows:
From our meeting yesterday:
Dec 17 2018
I see another problem here:
We're going to rebuild the extension package today from the latest code version and install it across the fleet.
While I guess we should create a new ticket to talk about MainObjectStash is used and where to migrate it.
I think adding an ENV variable to service-runner is probably the way to go.
Dec 14 2018
The application server layer https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/production/modules/mediawiki/templates/apache/mediawiki-vhost.conf.erb#14, and the caching layer https://gerrit.wikimedia.org/r/c/operations/puppet/+/478680/6/modules/varnish/templates/text-frontend.inc.vcl.erb are set to recognize the cookie PHP_ENGINE and send traffic to php-fpm if the value is php7.
To add to what @Tgr found, we have to search for usage of MediaWikiServices::getInstance()->getMainObjectStash(); as that's what that method uses under the hood.
Dec 13 2018
Dec 12 2018
I was asking because looking at what's currently stored in the "service", I see both mwsession objects (that are created I guess by the user session), and objects that have the form $wiki:echo:(alert|seen|message) which seem to be created by... Flow?
I don't think we need to overthink this, but knowing what kind of latency increase we can expect might drive us to choices of implementation technologies different from the ones we currently picked.
Dec 11 2018
Is this still unresolved? If so, it should be marked as a blocker to the php7 transition. @Anomie do you think there is anything else left to do?
I don't think this is the pattern widely adopted in our codebase.
Dec 10 2018
I did some benchmarks , using the same setup I used for T206341, with tideways enabled and disabled. I could not notice any clear trend besides a slight variance due probably to external factors.
Dec 7 2018
Dec 6 2018
I would add another requirement: