Page MenuHomePhabricator

Wind down use of project ID and project name equivalency in OpenStack
Closed, ResolvedPublic

Description

Since we have a very old system that has continuously operated for some time and a variety of assumptions and existing policies around access, we have depended on diverging from the upstream OpenStack practice of using random hash IDs for projects instead of assigning a specific value as the project ID (we use the project name). Over time this ended up requiring us to patch the actual code files (with a very small change) to keep doing what was abandoned upstream.

It's about time we started to actually remove dependencies on this in our code and the setup in the environment to not require that. This should include trying to make it so that we can still use project names and not have to manually look up ids, hopefully. Most code that lists out things should be capable of doing this anyway. It may require us to look into setting up more implied roles/policies, TLS on keystone, etc.

The low hanging fruit should be tasks for reviewing openstack-focused scripts for dependency on the equivalency. Please update a list of these below:

  • nfs-exportd
  • wmcs-wikireplica-dns
  • wmfkeystonehooks
  • maintain-dbusers

Event Timeline

Bstorm triaged this task as Medium priority.Feb 9 2021, 4:26 PM

One of the first things to understand here is why our CLI doesn't support names. Upstream docs suggest you can select one of --os-project-id OR --os-project-name. However, in our CLI, names just fail to select anything (you get empty results on list commands). That suggests to me that something in our policies prevent reading the name somehow.

One of the first things to understand here is why our CLI doesn't support names. Upstream docs suggest you can select one of --os-project-id OR --os-project-name. However, in our CLI, names just fail to select anything (you get empty results on list commands). That suggests to me that something in our policies prevent reading the name somehow.

I believe this is because the project id is already selected via the env, so overspecifying on the commandline is producing weird behavior. This should largely be sorted by further adoption of clouds.yaml https://phabricator.wikimedia.org/T337577

Andrew claimed this task.

New projects will now be created with a uuid instead of an id == name. Existing projects will continue to have the same ID they've always had, which means all the scripts name-checked in the task description will keep working as before. If/when new projects are added to those scripts they will need to be added by ID rather than by name.

See for completed work on this topic.