Page MenuHomePhabricator

Toolforge: consider decoupling user & accounts from CloudVPS accounts
Open, MediumPublic

Description

For the context of this ticket, we have 3 kind of accounts:

  • CloudVPS accounts (those managed by keystone). Stored in LDAP
  • Toolforge user accounts (today, same as CloudVPS accounts)
  • Toolforge tool accounts, (managed by toolsadmin, kind of LDAP groups). Stored in LDAP.

There is some level of multi-tenancy within the multi-tenancy (Toolforge tool accounts being CloudVPS accounts prefixed by tool.xxxx).
This design has some benefits and also some drawbacks.

Some examples of benefits:

  • integrated Developer Account experience
  • NFS file permissions

Some examples of weirdness produced by the account situation:

Did we ever consider breaking this into completely separated account realms? Would that break the Wikimedia Developer Account notion?
Perhaps this problem will go away as soon as we reach a point in Toolforge in which we don't need login servers (i.e, bastions).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Multi-host NSS in Cloud VPS is provided by the LDAP directory, so I'm not entirely sure what realm separation looks like in this case. Are you imagining a project local LDAP directory that is somehow blended in with the shared LDAP directory? Or Puppet managed /etc/password entries similar to those used in the "prod" realm? Or something else entirely? I'm not sure that I understand the problem statement.

I'm pretty sure that I do not agree to a distinction between a "Cloud VPS account" and a "Toolforge user account". These are both in my mind identical to a "Wikimedia developer account".

The tool.xxxxx accounts were originally a general purpose feature available to all Cloud VPS called "service groups". In T162945: The future of service groups and service users on Labs we removed the functionality from MediaWiki-extensions-OpenStackManager leaving Striker as the only UI for managing such LDAP directory entries.

Toolforge today needs "tool accounts" to provide two things: a unix group to allow shared access to a the tool's files by multiple maintainers, and a unix user to own running processes on behalf of the maintainers group. These constraints could shift to other systems in a future where direct management of shared files is external (for example if Toolforge become pure push-to-deploy and shared access files only exists in a version control system) and process ownership is managed in some other way (for example if Toolforge removed Son of Grid Engine support and only runs workloads in Kubernetes namespaces). As long as we have NFS and the grid though I'm not sure I see a reasonable path to removing the need for unix users and groups which represent a tool.

Andrew triaged this task as Medium priority.Apr 13 2021, 4:19 PM
Andrew moved this task from Inbox to Graveyard on the cloud-services-team (Kanban) board.