... I suppose another option is to leave OpenStackManager in place but unused apart for user creation, until we make wikitech SUL and move all developer account creation to Striker.

Doesn't Striker support doing this? We could just take the account creation logic out of Striker and have people create accounts that way.

In T196171#4301425, @Harej wrote:

Doesn't Striker support doing this? We could just take the account creation logic out of Striker and have people create accounts that way.

Yes, that solution is described in T179463: Create a single application to provision and manage developer (LDAP) accounts. Doing this would mean developing a new Django based application, getting it through security review, and getting it deployed followed by some amount of support for fixing bugs once it is rolled out. Not impossible at all, but not a trivial amount of work either. It is my preferred long term solution, but it would be nice to find a way to keep that from blocking the removal of MediaWiki-extensions-OpenStackManager from wikitech which is the main blocker to hosting wikitech in the main wiki cluster.

This sounds hacky, but until we provision a new identity management application, couldn't we just tell people to sign up via Striker?

In T196171#4304295, @Harej wrote:

This sounds hacky, but until we provision a new identity management application, couldn't we just tell people to sign up via Striker?

Yes, that would be possible. It would not be too difficult to make some mostly cosmetic changes to the workflow there as well to make that a bit less confusing. The most efficient thing to do by time and effort would be to combine the developer account and Toolforge use-cases into a single tool (Striker). In the longer term however that may be working counter to other goals (e.g. streamlining the Toolforge on-boarding process).

When I started planning Striker my intent was to hide as many of the "power user" use-cases as I could so that the experience of joining and using Toolforge was as simple and direct as possible. The assumption was that a typical new Tool maintainer does not care about VPS instances, Gerrit, or even Phabricator; they care about deploying a webservice or bot to help on their home wiki. I still generally believe this, so I'm hesitant to "temporarily" move in the other direction because I know that once the pressure is off we are less likely to build the better solution (T179463).

Is this still stalled? CAS-SSO was rolled out earlier this year

That's a good question! We'll review that.

I'm not sure the the introduction of CAS service has done anything to change the world here. CAS is backed by the Developer account LDAP directory but only does authentication and does not provide any account creation system which is what this ticket is about.

Yes, but we stalled waiting for the rollout so we'd know what it looks like. It might actually be stalled on us not working on it now 😁

I think that T319405: Create an IDM for Wikimedia developer accounts is going to be the likely resolution of this task as the practical implementation of T179463: Create a single application to provision and manage developer (LDAP) accounts.