Page MenuHomePhabricator

[Regression] some beta cluster wikis using official logos
Closed, ResolvedPublic

Description

The cluster of wikis in the deployment-prep project (https://meta.wikimedia.beta.wmflabs.org/wiki/Special:SiteMatrix) used to have special logos set which complied with the Cloud Services TOU prohibition on using Wikimedia Logos. I noticed recently that there has been some regression here with at least the metawiki work-alike using what appears to be an official logo (although the Foundation logo rather than the meta logo.

On https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?useskin=vector there is an overlay added via a css rule that labels the wiki as being part of the beta cluster, but https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?useskin=timeless has no such fix.

Acceptance criteria

  • The beta cluster should not show production logos
  • Fix display of old vector (skinversion=1) with regards to invalid 1x and 2x values
  • Apply the cloud logo to beta cluster instances

This all seems a likely side effect of changes which have been happening in the skin layer of MediaWiki and configuration drift.

Event Timeline

Jdlrobson added a subscriber: Jdlrobson.

This requires a config change and the needed changes are described on https://m.mediawiki.org/wiki/Manual:$wgLogos

Let me know if you need any help.

This requires a config change and the needed changes are described on https://m.mediawiki.org/wiki/Manual:$wgLogos

Let me know if you need any help.

If you've made those changes necessary, it should be your responsibility to fix them.

This requires a config change and the needed changes are described on https://m.mediawiki.org/wiki/Manual:$wgLogos

Let me know if you need any help.

These overrides exist -- https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings-labs.php#L372-L384 -- but apparently that's not enough to actually set the logos anymore.

Hey @bd808 Those logos only apply to old Vector and other skins. You'll need to design a new logo in the new format for compatiblity. Specifically youll need to override wordmark and icon definitions

If none of the existing logos apply please feel free to request one on T244486, you can also disable them and fallback to text.

As you can imagine there's a lot of them and only so many designers.

If the logo is an issue you can also rollback to old Vector but the assumption was we likely want to be forward thinking with our testing in beta. Updating config will also benefit other skins - namely Minerva and Timeless. Note that essentially new Vector should be considered as if it's a completely new skin.

Hey @bd808 Those logos only apply to old Vector and other skins. You'll need to design a new logo in the new format for compatiblity. Specifically youll need to override wordmark and icon definitions

If none of the existing logos apply please feel free to request one on T244486, you can also disable them and fallback to text.

As you can imagine there's a lot of them and only so many designers.

If the logo is an issue you can also rollback to old Vector but the assumption was we likely want to be forward thinking with our testing in beta. Updating config will also benefit other skins - namely Minerva and Timeless. Note that essentially new Vector should be considered as if it's a completely new skin.

@Jdlrobson thank you for the feedback, but you do seem to be assuming that it is my job to follow up on properly testing and deploying the work done by your team. This is an incorrect assumption. You need to take care of this violation of the Cloud VPS TOU caused by your software changes which have been deployed to servers in the deployment-prep project without proper configuration.

Getting the logos/wordmarks/whatever you need created is likely a task that some technical volunteers would be happy to help with if you give them proper instructions. This might be a great opportunity to practice making and refining those instructions in preparation for the hundreds of similar images that will need to be created when new vector is rolled out to the content wikis.

From what I can see here, the problem is that wmf-config/InitialiseSettings-labs.php inherits from wmf-config/InitialiseSettings.php without any overrides. That doesn't seem like a good situation to me based on what you are telling me and an architectural decision that I would urge be reconsidered.

There is an assumption here that the recent changes to Vector broke this, but I don't think that's true. Assuming we've always been defaulting to values in InitialiseSettings on labs instances, based on a git bisect of mediawiki-config it seems like there's been a violation of the Cloud VPS TOU since at least 2014 (I got bored bisecting) which has gone unnoticed on the mobile domain which has been using the logo that Vector now uses for some time. The software changes in Vector have thankfully made this situation more obvious.

The current situation is that any time a production wiki customized their logo, the new logo got inherited by the beta cluster.

I don't know enough about the Cloud VPS TOU, but it seems like the best thing to do here would be to start with disabling all those overrides. I'm not sure what the best way to do that is. The brute force way would be to copy every single entry in wmf-config/InitialiseSettings.php - but there's a lot of them at this point and that's prone to the same breakage when new projects enable logos - perhaps someone in RelEng could advise on how to rethink the -labs.php file.

It does seem given the state of affairs, that documentation must be improved. For the record, this is the first time I'm hearing about Cloud VPS terms of use and I don't see any mention on https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Change_the_logo_of_a_Wikimedia_wiki or https://www.mediawiki.org/wiki/Manual:$wgLogos of this consideration. I think one thing that should be done ASAP is that it should be made clearer that when enabling a logo, its beta cluster equivalent in -labs.php should be explicitly disabled with a link to the VPS TOU.

Practically speaking, the short term fix would be brute force fix would be to add the following into wmfLabsOverrideSettings() in wmf-config/InitialiseSettings-labs.php and then intentionally re-enable logos for these labs projects as necessary:

$wgLogos['1x'] = false; // this is the same as $wmgSiteLogo1x
$wgLogos['icon'] = false;
$wgLogos['wordmark'] = false;
$wgLogos['tagline'] = false;

The longer-term fix would be to stop inheriting config from production in labs. Does that make sense?

I am sorry I gave you the assumption that it was specifically "your job" to fix it. That was not my intention. My intention thus far has been a good faith effort to describe to you as the creator of this ticket what is happening and begin a discourse on how we (as in anyone!) might fix it.

Hey @Jdlrobson given the situation is one where the Beta Cluster is now violating the VPS Terms of Use (for good reason, the trademarks are a big way people distinguish if they're on a real/production wiki or not, and this situation could confuse users), can we please revert this change and prepare configuration changes to prevent it from happening when it rolls out again? We can't really have this be the state of Beta Cluster for very long. I'd prefer that code be revert tonight/tomorrow morning.

greg triaged this task as High priority.

@greg - we’re looking over this today and doing some analysis but probably won’t be able to get a fix out immediately as there is no one patch that we can easily revert without affecting current logos in production. As @Jdlrobson mentioned before (T274210#6813986), the issue is due to the beta cluster inheriting production logos which seems to have been around for a while. Fixing this would require a change to the configuration of the beta cluster. We're looking at other options on short-term fixes and will follow up with an update later today.

@Jdforrester-WMF - could we ask you for a bit of guidance here if you have a minute? @Jdlrobson suggested you might have some thoughts on the ideas proposed in T274210#6813986

Jdlrobson removed Jdlrobson as the assignee of this task.EditedTue, Feb 9, 11:38 PM
Jdlrobson removed a subscriber: ovasileva.

Just to set expectations I'm in training this week so my availability it not great. As Olga say, there is no patch to revert here, the patches landed many months ago and reverting them would i break the logos of production wikis.

I've spent some time looking at the monolith PHP file that is InitialiseSettings-labs.php and I'm not 100% sure how to do this so definitely need some help from RelEng (Antoine? James?).

If I'm reading correctly, it looks like InitialiseSettings-labs.php can override keys in InitialiseSettings.php provided the keys are prefixed with "-" is that right? That said I've made mistakes hereb efore.

So in the case of https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings-labs.php#L372-L384 the reason the logo doesn't apply to https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?useskinversion=1 is because no entry for 'wikipedia' has been defined and wmgSiteLogo1x should be -wmgSiteLogo1x ... am I reading that correctly?

I also see there is a logos.php file (https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/logos.php#L14) I'm not sure how that plays into all this.

Small progress: I've submitted https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/663057 so that the risk of changing logos here is made clearer in future.

If I'm reading correctly, it looks like InitialiseSettings-labs.php can override keys in InitialiseSettings.php provided the keys are prefixed with "-" is that right? That said I've made mistakes hereb efore.

So in the case of https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings-labs.php#L372-L384 the reason the logo doesn't apply to https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?useskinversion=1 is because no entry for 'wikipedia' has been defined and wmgSiteLogo1x should be -wmgSiteLogo1x ... am I reading that correctly?

Yes. Per the top of operations/mediawiki-config/wmf-config/InitialiseSettings-labs.php:

# Usage:
# - Prefix a setting key with '-' to override all values from
#   production InitialiseSettings.php.

I imagine that this is caused by the switch to logos.php and its effect on the Beta Cluster. My first thought was that it was related to the order of operations, but wmfGetVariantSettings() (with the new logo configuration variables like wmgSiteLogo1x, wmgSiteLogo1_5x, etc.) are set to the production values and then have space to be over-ridden by wmfApplyLabsOverrideSettings().

There shouldn't be a need for a wikipedia entry in the InitialiseSettings-labs.php over-rides; it should inherit from default.

The config is clearly not being correctly applied, however:

$ ssh deployment-deploy01.deployment-prep.eqiad1.wikimedia.cloud                                                                                          Wed 10 Feb 16:54:40 2021

jforrester@deployment-deploy01:~$ mwscript eval.php --wiki=enwiki
> var_dump( $wgLogos );
array(7) {
  ["1x"]=>
  string(39) "/static/images/project-logos/enwiki.png"
  ["1.5x"]=>
  string(44) "/static/images/project-logos/enwiki-1.5x.png"
  ["2x"]=>
  string(42) "/static/images/project-logos/enwiki-2x.png"
  ["icon"]=>
  string(45) "/static/images/mobile/copyright/wikipedia.png"
  ["wordmark"]=>
  array(3) {
    ["src"]=>
    string(57) "/static/images/mobile/copyright/wikipedia-wordmark-en.svg"
    ["width"]=>
    int(119)
    ["height"]=>
    int(18)
  }
  ["tagline"]=>
  array(3) {
    ["src"]=>
    string(56) "/static/images/mobile/copyright/wikipedia-tagline-en.svg"
    ["width"]=>
    int(117)
    ["height"]=>
    int(13)
  }
  ["variants"]=>
  NULL
}

>

Change 663263 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Labs should override all logo definitions

https://gerrit.wikimedia.org/r/663263

@Jdforrester-WMF the above patch might do it, but I have no idea. Feel free to tear apart my patch or make modifications. I'll be around a bit later in the day (PST afternoon).

Change 663263 merged by jenkins-bot:
[operations/mediawiki-config@master] Labs should override all logo definitions

https://gerrit.wikimedia.org/r/663263

Hey @greg it looks like the above patch doesn't seem to have worked (unless beta cluster can take longer than 1hr to update).
https://en.wikibooks.beta.wmflabs.org/wiki/Special:Version?useskinversion=1 is not showing the correct logo.

I'm not sure what's going wrong with the config here, this is not my area of expertise. Could somebody in Release Engineering take a look at why the config values in InitialiseSettings-labs.php is not being applied here ?

There was https://phabricator.wikimedia.org/T274526#6824553 from @hashar so could have been affected by that job being stuck maybe?

Change 663263 merged by jenkins-bot:
[operations/mediawiki-config@master] Labs should override all logo definitions

https://gerrit.wikimedia.org/r/663263

diffConfig
-    "wmgSiteLogo1x": "/static/images/project-logos/enwiktionary.png",
+    "wmgSiteLogo1x": "/static/images/project-logos/betacommons.png",
-    "wmgSiteLogo1_5x": "/static/images/project-logos/enwiktionary-1.5x.png",
+    "wmgSiteLogo1_5x": false,
-    "wmgSiteLogo2x": "/static/images/project-logos/enwiktionary-2x.png",
+    "wmgSiteLogo2x": false,
-    "wmgSiteLogoIcon": "/static/images/mobile/copyright/wiktionary.svg",
+    "wmgSiteLogoIcon": false,
@ 2 dppx
.mw-wiki-logo {
    background-image: url("");
    background-size: 135px auto;
}
@ 1.5 dppx
.mw-wiki-logo {
    background-image: url("");
    background-size: 135px auto;
}
.mw-wiki-logo {
    background-image: url(/static/images/project-logos/betacommons.png);

The patch is definitely live and having the expected effect from a MW perspective :)

Jdlrobson lowered the priority of this task from High to Medium.EditedThu, Feb 11, 9:07 PM

It seems like at the time of my last message the change was not live on the beta cluster ( I was seeing the official wikibooks logo)
Now i'm seeing

so the original posted issue of -labs breaking terms of use is resolved

@Krinkle is now describing a much different and more manageable problem that I can work with.

Note skin version 2 is the default for all wikis and this is working as expected:
https://en.wikibooks.beta.wmflabs.org/wiki/Special:Version?useskinversion=2

Should wgSiteName be updated here e.g. "Wikibooks (labs)"?

Change 665192 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Restore logos on Vector (classic version) and use cloud icon for labs

https://gerrit.wikimedia.org/r/665192

Given the lack of input on the site name, I'm going to leave that for now and just focus on the logos.

Change 665192 merged by jenkins-bot:
[operations/mediawiki-config@master] Restore logos on Vector (classic version) and use cloud icon for labs

https://gerrit.wikimedia.org/r/665192

Mentioned in SAL (#wikimedia-operations) [2021-02-19T00:26:53Z] <urbanecm@deploy1001> Synchronized static/images/project-logos/wikimedia-cloud-services.svg: 686acba2f31df0d454c6f1c506c042af50b5cce0: Restore logos on Vector (classic version) and use cloud icon for labs (T274210) (duration: 01m 07s)

Jdlrobson claimed this task.
Jdlrobson updated the task description. (Show Details)

This should all be fixed. Please open a new ticket if you find any more problems.

The cloud logo is now showing for any labs instance unless a specific logo has been defined

Most importantly this should be future proofed now against future logo deploys.