Page MenuHomePhabricator

Toolforge search results does not show all maintainers
Closed, ResolvedPublic

Description

Toolforge search results does not show all maintainers.

Ex: Interaction timeline
https://tools.wmflabs.org/admin/tools#!/search/interaction-timeline 2 Maintainers
https://tools.wmflabs.org/admin/tool/interaction-timeline 3 Maintainers

Screenshot-2018-2-5 Tool information interaction-timeline - Wikimedia Toolforge.png (545×1 px, 42 KB)

Screenshot-2018-2-5 Hosted tools - Wikimedia Toolforge.png (539×1 px, 42 KB)

Event Timeline

bd808 added a subscriber: bd808.

My first guess was something different about caching between the two views of the data, but looking in the change history I can see that @dmaza was added as a maintainer of the tool on 2017-11-09 so that doesn't make any sense as the root cause.

Are there any docs on how to get a dev environment running locally? I can't find them

The admin tool doesn't have a good local development story. It's tangled up with several data sources that only exist inside Toolforge/Cloud VPS. I've worked on it locally before by ssh tunneling, but its not pretty.

We do have https://tools.wmflabs.org/admin-beta/ as a place to stage and test proposed changes. There is also no special access granted to that tool's processes, so all the things it does should be testable from a tools bastion or interactive session on Kubernetes.

I think the issue is that dmaza is not part of the users table.

On tools.html, it checks that the maintainer is part of users before displaying it while on tool.html displays maintainers without checking. I think that's why we see it on the details page tool.html and not on the list.

I've noticed that my user (ID: 20036) is also missing from the users table in the toollabs_p database. The last user ID added there was 17271.

It seems that the updatetools script is not running on tools-services-* due to a missing service configuration.

Besides that, the script fails to run manually:

tools.admin@tools-services-01:~$ /usr/local/bin/updatetools 
Traceback (most recent call last):
  File "/usr/local/bin/updatetools", line 72, in <module>
    update_users_table(db)
  File "/usr/local/bin/updatetools", line 58, in update_users_table
    account = pwd.getpwnam(project_member)
KeyError: 'getpwnam(): name not found: legofan4000'

I'll take a look at this later this week.

GTirloni triaged this task as Medium priority.

KeyError: 'getpwnam(): name not found: legofan4000'

legofan4000 was renamed to macfan4000 in T165624 with some manual LDAP LDIF patches. That may have made something horrible for the updatetools script to deal with.

Mentioned in SAL (#wikimedia-operations) [2018-10-16T12:52:39Z] <gtirloni> T186571 removed legofan4000 user from project-tools group (leftover from T165624 legofan4000->macfan4000 rename)

@bd808 thanks for the pointer! User legofan4000 was in LDAP group project-tools and the script was barfing when trying to find the real user.

I've confirmed @dmaza now shows as a maintainer and the users table was updated (went from ~1400 to ~1700 users). The script is running on tools-services-02 as a service.

Mentioned in SAL (#wikimedia-cloud) [2018-10-16T15:13:54Z] <bd808> (repost for gtirloni) T186571 removed legofan4000 user from project-tools group (leftover from T165624 legofan4000->macfan4000 rename)

Mentioned in SAL (#wikimedia-cloud) [2018-11-26T17:34:37Z] <gtirloni> T186571 removed legofan4000 user from project-tools group (again)

legofan4000 showed back in project-tools group and was making updatetools break again. I've removed it a second time.