There's some awfully convoluted and hackish system set up at https://www.mediawiki.org/wiki/Developer_access for requesting a Gerrit/Git/Labs account currently. This process requires manual approval. This simply isn't scalable or sensible. It should be possible to create an account without human intervention.
Version: unspecified
Severity: normal
This seems like the most classic case of a blocker to me.
Can someone please describe the current process to create a Git/Gerrit account and what needs to be done to remove the need for human intervention in the current process? This would greatly help moving this bug forward, I think.
In the current process, for users who have never had SVN access, accounts are created via MediaWiki. There's nothing special about it. In fact, a number of volunteers were granted access to create accounts at the Wikimedia hackathon in DC.
For users that already have SVN accounts, we have to link their SVN account with a new Labs account. At this point, there's likely very few people with SVN accounts that don't already have Labs accounts.
There's one blocker for allowing self-registration. In labsconsole, when a user is created, there's nothing stopping any Labs project member from adding them into a Labs project they are a member of (that's by design), which would give them shell access. We'd like to limit shell access to real people we've actually had some kind of discussion with. We need to limit member access to users who have been added into a group by an admin with some proper level of access, so that we can ensure a user is a legitimate user.
If someone would like to help with this, they can push in a change to OpenStackManager to support it. A "approved-shell" group could be created in labsconsole's config, and we can have the "Manage projects" interface restrict users available to be added to projects by membership in the MediaWiki group. Access to the "approved-shell" group could be managed by wiki admins.
It would be nice for this to also restrict accounts from being created that conflict with accounts on Wikimedia SUL (unless, of course, we're talking about the same user). That, of course, makes this much more complicated, so I suppose it's not a requirement, but it'd be nice.
It would be nice, but we may already be in that situation now. With OAuth we'd be able to enforce this. (I want OAuth for so, so many things).
(In reply to comment #3)
At this point, there's likely very few people with SVN
accounts that don't already have Labs accounts.
If you mean active SVN users you're probably right so this is not a big problem, but https://svn.wikimedia.org/users.php lists 443 users "not ready for git" so I suppose many have not been migrated.
(In reply to comment #4)
It would be nice for this to also restrict accounts from being created that
conflict with accounts on Wikimedia SUL (unless, of course, we're talking about
the same user). That, of course, makes this much more complicated, so I
suppose it's not a requirement, but it'd be nice.
(Without Looking at said extension capabilities) Could we not adapt (Do we even need to?) AntiSpoof to look at the CentralAuth user table?
(In reply to comment #7)
(In reply to comment #4)
It would be nice for this to also restrict accounts from being created that
conflict with accounts on Wikimedia SUL (unless, of course, we're talking about
the same user). That, of course, makes this much more complicated, so I
suppose it's not a requirement, but it'd be nice.(Without Looking at said extension capabilities) Could we not adapt (Do we even
need to?) AntiSpoof to look at the CentralAuth user table?
No. labsconsole is purposely not a part of the cluster, so it can't look at the CentralAuth user table.
(In reply to comment #6)
(In reply to comment #3)
At this point, there's likely very few people with SVN
accounts that don't already have Labs accounts.If you mean active SVN users you're probably right so this is not a big
problem, but https://svn.wikimedia.org/users.php lists 443 users "not ready for
git" so I suppose many have not been migrated.
users.php is very outdated, and looks at a file that isn't updated anymore. Many of the users listed as N already have accounts.
MZMcBride: I fail to see how this qualifies as a blocker.
Did you refer to human response times to requests?
(In reply to comment #11)
MZMcBride: I fail to see how this qualifies as a blocker.
It blocks development work when people can't dive in to the development process. But you're right, this bug probably doesn't need to be marked as a blocker.