Since the early days of OpenStack we've used a model where project ids and project names are identical. This was the norm in early OpenStack releases.
Modern openstack assigns arbitrary UUIDs to new projects, allowing project names to be changed on the fly without breaking db relationships. Our current deployments skip the UUID issue via a 'wmfkeystonehooks' hack that resets the project id to the project name.
UUIDs are annoying, but diverging from the upstream is also getting ever more annoying. If we adopt the usptream UUID practice, we'll have to locate and fix all of our scripts and workflows that rely on project id and name being the same.
The good news is we can change these workflows incrementally without actually breaking anything in the meantime. The breakage will only come later when we remove the keystone hack.
[x] Designate domain assignment (e.g. myinstance.myproject.eqiad1.wikimedia.cloud) uses project id rather than project name
[] Cumin, spicerack, and cookbooks take project ids rather than project names. Either users will have to start using UUIDs or something in the cumin code will need to do a lookup and take distinct --project-id or project-name arguments
[] mwopenstackclients.py needs an audit to confirm that arguments are properly named 'project_name' or 'project_id' and used accordingly.