Closing as Declined, since this is a non-issue

Change 579026 abandoned by Dzahn:
[operations/puppet@production] move 20 new codfw parsoid servers into production

FWIW, it's more than just the favicon. These also 404

Blocker ---> UBN!

TL;DR: we were unable to reproduce a corruption in this iterartion

Right, but I asked originally which we should do, host at same wiki domain at /beacon, or use a separate domain, and I was told to use a separate domain.

Also relevant: T262996: Don't set cookies in traffic layer for non-user facing domains (avoid false third-party cookie warning) ?

In T226986#6467482, @Ottomata wrote:

Huh, I'm pretty sure I discussed this with bblack and/or traffic team when we were first setting up eventgate-analtyics-external, and they preferred that the intake service got its own unique URL, rather than serving it in the wiki domains.

Change 627891 had a related patch set uploaded (by Sbailey; owner: Sbailey):
[mediawiki/services/parsoid@master] WIP adding extra key component to follow id's to avoid duplication

Change 624972 merged by Dzahn:
[operations/puppet@production] ci/pipeline/builder.pp: Add ruamel package

This is a new client-side error that has occurred with the current release relating to T259784. Possibly a deployment blocker?

NZ = CC (Visa, MC, AMEX) and Paypal
AU = CC (Visa, MC, Amex, JCB) and Paypal

Huh, I'm pretty sure I discussed this with bblack and/or traffic team when we were first setting up eventgate-analtyics-external, and they preferred that the intake service got its own unique URL, rather than serving it in the wiki domains.

Mentioned in SAL (#wikimedia-operations) [2020-09-16T18:14:12Z] <catrope@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Enable Vector search in header on testwiki and officewiki (T262207) (duration: 01m 04s)

racked

We are also seeing quite a few of those with "Can't find revision 0". Perhaps 0 should be handled as a special case.

for the record, I just confirmed: eqiad gives a correct result as well:

Change 627566 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Fix crashers in TableFixups handler + document unhandled scenarios

Change 627566 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Fix crashers in TableFixups handler + document unhandled scenarios

racked

In T262315#6446834, @eprodromou wrote:

I think this is dependent on T262319 and probably needs to wait until after it's done.

Change 627791 merged by jenkins-bot:
[mediawiki/core@REL1_34] Fix failure of rebuildLocalisationCache.php due to RL hook

@Pcoombe @MBeat33 @spatton can we get a confirmation that this is good to go to prod?

@EMartin could you help remind us of the payment types currently available in NZ and AU through ingenico? I can't seem to find that info in asana. the EN6C stuff kinda gets blended together.

The revert solved the issue for now. Still, we need to figure out what was going wrong, most apparently in the wikifeeds -> restbase -> aqs link when going through the proxy.

Change 627884 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable Vector search in header on officewiki and testwiki

Keeping this alive until we can figure out the root cause. But this should not be broken anymore.

In T226986#6467398, @Krinkle wrote:

DNS is relatively quick and well-cached on-device, local network, and in middleware networks. Starting to establish more than one primary connection on a majority of page views is something we phased out 5+ years ago and would be great not to bring back without further research and consideration first.

The latency of events is indeed not critical, but there is a performance cost. It's all happening on the same device and network, consuming limited battery and network resources.

@hnowlan Does this look like a routing issue?

Telia Implementation Team,
We ended up having to swap the optic on our end of the link, as its TX out was not acceptable.  Its now showing a much better TX light out (-5) at our dmarc panel.  Can you investigate and report back you RX of our light?
Additionally, we are RX light from Telia, but only at -33, so unclear what is wrong on that end.  Please confirm you are sending light at approx "Tx Power:  0.65160 mW (-1.86019 dBm)"?  If so, I'll have to open a ticket with Equinix Ashburn staff to trace the link and report where we're seeing the failure.
Please advise,

Mentioned in SAL (#wikimedia-operations) [2020-09-16T18:00:09Z] <brennen@deploy1001> Synchronized php-1.36.0-wmf.9/extensions/MobileFrontend: Backport: [[gerrit:627793|Check $coords matched some nodes before comparing contents (T263034)]] (duration: 01m 06s)

First of all, cool stuff!

Should the link always go to the article tab? Or should the history tab point to the history tab of another language?

@Johan I think this is the main question. Can you frame this request from a user need / workflow perspective? It may help clarify some of the open questions.

Change 627888 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Remove colon from amount header

Should we bother? Tabs are short. I currently can't see the end of the title for any of the (only!) five tabs open in the window I'm writing this in. If you put something at the start, it'd mean I couldn't see the actual topic of the page...

I've been working with Chris on this today, and after testing, it was determined our optic in xe-3/3/7 was not outputting correctly. It measured a -1.x output from the module, but a patch plugged in saw it in the teens and above. Swapping the optic brings it back down to an output at our dmarc of roughly -5, which is more like the incoming light on our other links.

DNS is relatively quick and well-cached on-device, local network, and in middleware networks. Starting to establish more than one primary connection on a majority of page views is something we phased out 5+ years ago and would be great not to bring back without further research and consideration first.

Hey - this was brought to my attention, and we discussed it today at the I/F meeting. The outcome of our conversation was that @Volans and @jbond will do a final review pass and merge r621343 ~by the end of this week.

The configuration is exactly the same for staging and eqiad/codfw right now, so I'm not sure what's going on here. I'll have to dig into it further.

For the record, the service doesn't seem to be having any trouble in staging:

I'm going to review this task in order to review our plans there.

In T226986#6467370, @Krinkle wrote:

For EventLogging, we specifically moved away from separate domains to using /beacon so that the majority of non-deferred events that are sent off during user interactions do require separate connections to be established etc. It has been a while since we last quantified the benefits of this choice, so it's certainly worth revisiting.

Great, thank you! That was my thinking as well, but I wanted to confirm.

@CDanis this should be fine, the errors are fire-and-forget so this shouldn't cause any slowdown e.g. increased RTT waiting for a response, and there is no timing or anything that depends on this. I can't see any issue that would result, the DNS routing should be totally opaque.

For EventLogging, we specifically moved away from separate domains to using /beacon so that the majority of non-deferred events that are sent off during user interactions don't require separate connections to be established etc. It has been a while since we last quantified the benefits of this choice, so it's certainly worth revisiting.

Change 627793 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@wmf/1.36.0-wmf.9] Check $coords matched some nodes before comparing contents

Showcase done!

That might be related to the deployment of git-protocol-v2 on clients. For CI that was T256844 done on August 18th and 19th:

Change 434214 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Implement mediawiki.skin.variables.less for Vector

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/627889

@KBailly - thanks for the suggested fix! I just checked in a fix based on this, which should hopefully work across different SMW versions. I haven't tested it, but hopefully things are working better now.

In T263043#6467333, @Mholloway wrote:

I suspect that this line is our culprit. Does it need to be updated to use https? https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/8b7969653b3da43de4918d1ea89f4916a8b5ec9a/charts/wikifeeds/values.yaml#34

Hello @HuaSir and thanks for the report.

In T263043#6467333, @Mholloway wrote:

I suspect that this line is our culprit. Does it need to be updated to use https? https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/8b7969653b3da43de4918d1ea89f4916a8b5ec9a/charts/wikifeeds/values.yaml#34