I had a quick look, I agree with the above investigation (I reproduced as well) and can add (in case it's not obvious) that for some reason libenchant seems to prefer on ores1009 aspell instead of ispell. It is become even more complicated because of hunspell usage as well, lower down strace. I dug into it for about 1 hour or so without an obvious cause/solution being revealed to me.
I 'll remove myself from this if you don't mind. I guess I was added because of T240175#5723047 but that was an answer to a very cut and clear question. Overall, I honestly I have no idea what the project is about, nor how I could be of help (at least for now). Feel free to readd me if you disagree.
Thu, Dec 5
I 've deleted that instance. It's been a long time since we last used it and is probably not particularly useful right now. I 'll resolve this.
I should probably be removed as an admin. I have no usage of it and no idea what that machine is.
Feel free to delete machines and project.
For what is worth, I have no usage of these machines nor the project.
Wed, Dec 4
Tue, Dec 3
Do you think we can keep using the server without replacing the disk or do we have to buy 1 disk and keep on site in case the disk failed
Problem fixed by the change above
Mon, Dec 2
We haven't even started the process of refreshing those nodes and they host important services. I 'd rather we just replaced the disk.
Fri, Nov 29
need to be able to understand the pooled status
So it does look like it's service-runner specific then.
Thu, Nov 28
Wed, Nov 27
Tue, Nov 26
Mon, Nov 25
Fri, Nov 22
This was mentioned in T238890 (of which it is not a blocker) but we will anyway needs this for all services.
docker run --rm --entrypoint /bin/bash -it docker-registry.wikimedia.org/wikimedia/mediawiki-services-chromium-render:2019-11-22-134049-production runuser@5f6d4fdc14f8:/srv/service$ ls LICENSE app.js config.yaml lib package.json scripts spec.yaml test README.md config.dev.yaml dist node_modules routes server.js targets.yaml runuser@5f6d4fdc14f8:/srv/service$ dpkg -l chromium Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================-===================-===================-=============================================================== ii chromium 73.0.3683.75-1~deb9 amd64 web browser
Just so that you aren't caught off guard
Thu, Nov 21
More investigation in T238823. It's quite possibly expected.
Could be totally different but with @jijiki we 've seen this behavior elsewhere as well. The latest installment is T238789. Per that logstash dashboard, it's the mediawiki's that send the RST to the echostore.
\o/. Thanks for taking care of this!
Wed, Nov 20
krypton is no more since 7a36b4e7a94f486a400f0363c263c446c33bba80, resolving.
I 'll boldly resolve (no update since July), feel free to reopen
Tue, Nov 19
Should we resolve this?
This has been fixed in 3229da692ef3a003a860d6b0024c9ef4813ce13d. The reason production tagged releases are now again available is because we gave up on having swagger/openapi specs and removed helm.yaml (the thing informing the pipeline that integration tests should be run) in https://gerrit.wikimedia.org/r/#/c/mediawiki/services/zotero/+/538171/.
This has been done, resolving
Adding some extra info as we 've discussed with @ssingh before this task was filed. After the discussion it became obvious that a ganeti VM would not be a good candidate for this, mainly because of the disk size requirement.
Fri, Nov 15
I think it's in the ~35mins "schedule" now, but other than that, it's still present https://grafana.wikimedia.org/d/RIA1lzDZk/application-servers-red-dashboard?orgId=1&var-datasource=eqiad%20prometheus%2Fops&var-cluster=api_appserver&var-method=GET&var-code=200&from=1573809235233&to=1573845235233
I think we can solve this by just adding system:heapster role to our prometheus kubernetes group. I 'll try that approach but for now I am lowering to Low as it isn't causing an issue with metrics gathering (at least the metrics we currently rely on)
Thu, Nov 14
Namespaces and tokens have been created and populated. @Ottomata, you are clear for deployment. I am guessing after that we need LVS, discovery, public endpoint exposing.
Wed, Nov 13
I 'll be bold and resolve this since we now have fixed b). We can always reopen and evaluate if a) becomes an issue (aka I am going with 3.)
Tue, Nov 12
As noted in T91649 (duplicating here just for more dissemination), sentry is no longer open source (by the strict definition of the term). More at https://forum.sentry.io/t/re-licensing-sentry-faq-dAiscussion/8044
Sentry is no longer open source (by the definition of OSI and by the admission of upstream as well). More at https://forum.sentry.io/t/re-licensing-sentry-faq-dAiscussion/8044.
Nov 8 2019
All builds done on boron end up in /var/cache/pbuilder/result/* and we don't expire debs from there.
Nov 6 2019
Nov 4 2019
akosiaris@an-master1002:~$ telnet -4 backup1001.eqiad.wmnet 9103 Trying 10.64.48.36... Connected to backup1001.eqiad.wmnet. Escape character is '^]'.
As @Joe said, that's expected. It's how misbehaving services are killed in order to recover. Here's also a breakdown in case anyone is interested
IMPORTANT: The puppet CA cert (and correspondingly key), is used as a "master" (a failsafe in case the actual host key is not around) key for bacula backups. That is, if we lose it we won't be able to restore backups for hosts that no longer are around. This is documented under https://wikitech.wikimedia.org/wiki/Bacula#Restore_from_a_non-existent_host_(missing_private_key).
Let a minor comment, namely let's keep helium around for a bit more.
Nov 1 2019
Rolling it back. Per https://en.wikipedia.org/wiki/RDRAND and further tests, rdrand is already present in IvyBridge, which is what we pass as the base anyway.