The footer for Striker is:

Do we have any known requests from the community for such a tool as a replacement/enhancment for irc + mailing list + phabricator?

+1 from me as a Cloud VPS admin to proceed with creating this project

In T332777#8720353, @awight wrote:

My expectation of continuing to reuse the allocation was based on real-world observation of other projects I'm involved in, but it makes sense that there's a trade-off between hardware resources and staff overhead...

Fail fast has basically always been the behavior of maintain-dbusers. The historic fix would be one of delete the broken account (test-abogott5) or correct whatever is causing the account's failure.

Per https://wikitech.wikimedia.org/wiki/Help:Cloud_VPS_project#Reviews_of_Cloud_VPS_Project_requests:

The majority of project requests are approved, but there are some things which will cause further discussion:
...
"Umbrella" projects with a broad scope, such as all the work to be done by an engineering team or a large problem space.

"Umbrella" projects with broad scopes are difficult to track over time because of organizational changes and lack of continuity in ownership.

I have thought about this before, but while I was patrolling today I ended up wanting very much to have in-line diffs and consistent click targets to make the process a bit quicker.

Similar to, but not exactly the same as T316832: Mark notifs about approved/declined membership requests as read for all admins. Although I would have a hunch that if T316832 were implemented most admins would not feel the need for a "ignore this backlog because it is too deep" button. :)

In T224892#8709735, @Lectrician1 wrote:

Seriously? Could this like be updated in documentation?

T144713: Add a web shell allowing people to perform actions as their tool from striker could be considered a duplicate of this or a specific implementation of the desired feature. For now I think I will make this task a parent to that older task and we can continue to explore what the "best" solution is to the general problem.

The mediawiki-vagrant powered development environment is no longer supported.

In T281003#8707836, @Kizule wrote:

I think this needs updating, zoranzoki21* doesn't need to be listed here. https://gerrit.wikimedia.org/g/operations/puppet/+/8fa8a3032beb954f6181ab71b5415a61c08e63c1/modules/profile/files/toolforge/legacy_redirector.lua#636

https://botsin.space/@wikimedia_sal

T321919: Figure out and document how to call the Kubernetes API as your tool user from inside a pod has some information on possible ways for to interact with the Toolforge Kubernetes API from inside the Kubernetes cluster.

Make sure to read the warnings on that page about how this can fail. Also be aware that the community provided guidance on that page for a Python service is incomplete. The uwsgi container must be restarted for source code changes to take effect. The missing step would be to call the Kubernetes API to kill the running container or otherwise affect the termination of the active pod and creation of a new one. PHP reads files from disk again for each requests which makes that workflow simpler.

Account was approved.

This is not a declaration that this is a good idea, but if I understand the current enwp.org behavior, I think this would replace it:

diff --git i/modules/ncredir/files/nc_redirects.dat w/modules/ncredir/files/nc_redirects.dat
index dc52c09013..bbcc31d1d3 100644
--- i/modules/ncredir/files/nc_redirects.dat
+++ w/modules/ncredir/files/nc_redirects.dat
@@ -115,6 +115,7 @@ rewrite *wikimediaenterprise.com    https://enterprise.wikimedia.com

Apparently envvars can be used to override some settings. This could be combined with the idea of using k8s secrets for storage as well by using https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables.

Reported upstream as https://github.com/42wim/matterbridge/issues/2020

I think I have found a workaround for this. I granted the wm-bridegbot user a custom admin role in the Telegram chat. This seems to allow it to bypass the slow mode restriction. The custom role is titled "bot" and has all of the "what can this admin do?" toggles turned off.

Matterbridge's IRC handler has a MessageDelay knob that can be used to avoid rate limits. Unfortunately the Telegram handler does not have an equivalent function.

I have requested an account for the bot at botsin.space. They have a manual moderation queue for new accounts, so things are stalled until the account is approved or rejected upstream.

I think I should probably make the bot's toots unlisted too to avoid boring instance timeline clutter.

Stashbot does "own" the account. Moving to botsin.space because of defederation concerns seems reasonable.

Basically wm-bot serves the same relay bot role in the WMCS SAL logging path as logmsgbot does for wiki cluster SAL logging: app - → relay bot - → irc - → stashbot - → wikitech + sal.toolforge.org

In T320794#8693751, @SLyngshede-WMF wrote:

We actually have uid, cn and sn which are all by default set to the developer account username.

In T320794#8690975, @SLyngshede-WMF wrote:

Attributes we will be needing:

• wikimediaGlobalAccountName (MediaWiki SUL account name) (optional)

In T331841#8691196, @NicoleLBee wrote:

1. kubectl get pods to see if a toolhunt-api.worker pod exists
2. if it does, kill it with kubectl delete deploy toolhunt-api.worker
3. spin up a new pod with kubectl create --validate=true -f $HOME/www/python/src/deployment.yaml

In T330759#8681808, @bd808 wrote:

This revert is due to T331674: Some tool maintainers not showing in Striker UI following config change where it became clear to me that we have not yet changed the Keystone database to grant everyone the new roles (which I somehow thought had been done). At least in the tools project (Toolforge) the migration is half done. Users who had 'projectadmin' now have 'member', but 'user' has not yet been converted to 'reader'.

Rolling back to the prior settings.OPENSTACK_USER_ROLE and settings.OPENSTACK_ADMIN_ROLE values has fixed the issue with non-admin users not showing in the UI. It should also fix the originally reported issue of failing to find Phabricator accounts for maintainers. That was caused by the maintainer list being empty due to the config mismatch. Luckily all of this was a client configuration issue without any data loss in the canonical LDAP storage.

In T330759#8681804, @gerritbot wrote:

Change 896031 merged by Legoktm:

[operations/puppet@production] Revert "striker: Bump container version to 2023-03-09-005633-production"

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

>>> from striker.tools import cache
>>> users = cache.get_openstack_users()
>>> users.keys()
dict_keys(['glanceadmin', 'heat_stack_owner', 'admin', 'member', 'projectadmin', 'designateadmin', 'heat_stack_user', 'keystonevalidate', 'user', 'reader'])
>>> for role in users.keys():
...     print(role, len(users[role]))
...
glanceadmin 0
heat_stack_owner 0
admin 0
member 26
projectadmin 0
designateadmin 1
heat_stack_user 0
keystonevalidate 0
user 2406
reader 0

We changed the settings before the backing database for Keystone was updated. :/

We changed the values of settings.OPENSTACK_USER_ROLE and settings.OPENSTACK_ADMIN_ROLE today with https://gerrit.wikimedia.org/r/c/labs/striker/+/895140. This feels like the likely cause of strange behaviors. It may be entirely in this custom manager's _get_tool_users implementation:

class MaintainerManager(models.Manager):
    def _get_tool_users(self):
        if settings.TEST_MODE:
            # Hack to keep from trying to talk to openstack API from django
            # test harness
            return []
        users = cache.get_openstack_users()
        return (
            users[settings.OPENSTACK_USER_ROLE] +
            users[settings.OPENSTACK_ADMIN_ROLE]
        )

The service is working again because I live hacked the missing podsecuritypolicies grants back into the user-maintainer clusterrole, but this will break again as soon as someone runs the helm deploy for maintain-kubeusers.