Wed, Aug 14
PS2 looks good to me. I can try to deploy this later today or tomorrow, since there's no train this week.
Tagging with User-RhinosF1 to remind me to add proper browser info later
- rODPI operations-debs-prometheus-ipsec-exporter is the Phab mirror.
- https://github.com/wikimedia/operations-debs-prometheus-ipsec-exporter is the GitHub mirror.
As discussed on Slack, @cooltey will apply the letter-spacing value of Widget.MaterialComponents.Button to Widget.AppCompat.Button.Borderless 🎯
Mentioned in SAL (#wikimedia-releng) [2019-08-14T18:40:13Z] <hauskatze> github: Created https://github.com/wikimedia/operations-debs-prometheus-ipsec-exporter && forced replication to mirror changes # T230443
Flywheel & Product Metrics working presentation from earlier this year: https://docs.google.com/presentation/d/1CJFf-O4E7PW_eu05z-oBPwndqSn57BOnALDkN7QmhC0/edit#slide=id.g4e56811b09_0_14
Hey @cooltey, thanks for mentioning this. Quick question, are we currently using Roboto Medium 14sp with a letter-spacing value of 0.5sp for the buttons? If yes, let’s keep it like that! Thanks!
Change 530190 had a related patch set uploaded (by simetrical; owner: simetrical):
[mediawiki/core@master] Introduce TitleParser::makeTitleValueSafe()
I think default mode is checked because there's a separate pcache suffix for folks using the beta-mode -- this is targeted at clearing the non-beta-mode entries after a site-config switch.
One of the batched MW API requests is hitting this error:
@herron Done. Created as operations/debs/prometheus-ipsec-exporter,git. Inheriting permissions from operations/debs which means ldap/ops have "ownership" over that repository. Please let me know if further groups should "own" that repository.
The header was set during session_start(). I changed it by setting session_cache_limiter().
Change 530191 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/TimedMediaHandler@master] onRejectParserCacheValue: Correct name of target videojs module; add comment
Going to close this one based on earlier research we did (some documented here) and the likelihood that we're not going to use Advanced search for our purposes.
Change 530146 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Fixed the CSS class of Data item link in client wiki sidebar
The only POSTs I see in there are in setContainerAccess, addMissingHashMetadata, and doDescribeInternal, which all update existing files. Could be there's a hole in the logic of one of them that's dropping Content-Type, or that some files were missing it to begin with but it was being filled in on high-level fetches, or something, so they worked until something updated the data?
Change 530189 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/puppet@production] dumpsdistribution: fail back to labstore1006 properly
I'll do this shortly.
I think @jbond created some templates on Wikitech to onboard people, and there's an onboarding script as well. I don't know if that procedure is intended for this kind of access requests or for elevated permissions.
High or UBN priority?
Change 530188 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/dns@master] dumpsdistribution: set primary web to the server marked web
Hmm, I notice this in SwiftFileBackend.php:
Completed auto-reimage of hosts:
Not sure who to best ping about this at this time.
SpecialBlock shouldn't become a service; instead, SpecialPageFactory should be a service which instantiates SpecialBlock. See T222388.
Change 530186 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/puppet@production] toolforge: rebranding k8s control plane to control
CentralAuth disables output buffering and outputs directly, avoiding OuptutPage methods in SpecialCentralAutoLogin::doFinalOutput(). Any ideas why it might be doing that?
At this point, I'm going to leave this task open basically for just long enough for us to build new control plane nodes in toolsbeta. I don't think it requires us tearing down the test cluster for now.
Wow, this is not the first time the mobile team asked about using XTools APIs! I will say the same thing as before -- while XTools typically has very good uptime (upwards of 99.9% out of the year, according to my data), it probably should not be relied upon by something like the production Wikipedia iOS app. Our APIs are more for research purposes, user scripts, other Cloud Services tools, etc., not for applications that receive significant traffic. I can guarantee however that XTools is not going anywhere, provided it's within our control :)
At this point, we have ended up puppetizing the copying of puppet certs to act as etcd client certs as well as server certs in T215531: Deploy upgraded Kubernetes to toolsbeta with an "unstacked" control plane (separate etcd servers) because we found the process of dealing with node failure with a stacked control plane to be kind of awful.
Adding to discussion in order to discuss the proposal for admin users since that is a change from the behavior of the original system as well as to open the design proposal for comment/questions/rejection/redo in general.
@Jdlrobson also tagging Jon - it was pointed out to me that the work in https://phabricator.wikimedia.org/T117279 could help us here. We are working on supporting inline diffs in iOS - it looks like this would save us a step with pulling the separated diff from API:Compare and merging them to be inline. Is there any ETA on when https://phabricator.wikimedia.org/T117279 might make it into prod?
We're redesigning/restructuring the search approach a bit so this isn't valid anymore.
Change 508967 restored by GeoffreyT2000:
Remove title protection correctly for undeletions and imports
All tests merged.