Page MenuHomePhabricator

Toolforge search results does not show all maintainers
Closed, ResolvedPublic


Toolforge search results does not show all maintainers.

Ex: Interaction timeline!/search/interaction-timeline 2 Maintainers 3 Maintainers

Event Timeline

dmaza created this task.Feb 6 2018, 1:05 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 6 2018, 1:05 AM
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.

dmaza added a comment.Feb 6 2018, 2:20 AM

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

bd808 added a comment.Feb 6 2018, 6:37 PM

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 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.

dmaza added a comment.Feb 7 2018, 4:55 PM

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.

bd808 edited projects, added Tool-admin; removed Tools.Feb 23 2018, 12:54 AM

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>
  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 Normal priority.Oct 14 2018, 1:12 PM
GTirloni claimed this task.

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)

Bstorm added a subscriber: Bstorm.Oct 16 2018, 1:36 PM

@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.

GTirloni closed this task as Resolved.Oct 16 2018, 1:45 PM

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.