- display project name on project page and list
- display project name instead of id in project "subpages"
- instances
- dns zones
- database instances
- hiera keys
- puppet classes
- display project name on user project membership list
Description
Description
Details
Details
Related Changes in GitLab:
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Project page: Show project name up top, then ID | toolforge-repos/openstack-browser!10 | andrew | project_name_with_black | master |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • aborrero | T296411 cloud: decide on general idea for having cloud-dedicated hardware provide service in the cloud realm & the internet | |||
| Resolved | • aborrero | T297596 have cloud hardware servers in the cloud realm using a dedicated LB layer | |||
| Resolved | • aborrero | T324992 cloudlb: create PoC on codfw | |||
| Resolved | • aborrero | T338937 cloudlb: review swift/radosgw status | |||
| Resolved | Andrew | T341509 radosgw+keystone chokes on projects with '-' in their id | |||
| Resolved | Andrew | T274268 Wind down use of project ID and project name equivalency in OpenStack | |||
| Resolved | Andrew | T343158 Support OpenStack projects where project name != project id | |||
| Resolved | Andrew | T366679 openstack-browser support for projects where id != name |
Event Timeline
Comment Actions
One minor quibble, I think in the 'instances' section it should use the uuid, since that's what 'hostname -f' returns on the VM. I /think/ that's correct since it's the most unambiguous way to refer to the host.
The 'dns' section should show all the records, which means both records with uuid /and/ with project name.
Comment Actions
I'm actually hoping to find out that we will still be ensuring that project names are unique as well as project ids. If so I can fix the tool to use names as the visible keys and then do lookups as needed to translate the names to ids. I would like this mostly so that my awesomebar gives me suggestions like https://openstack-browser.toolforge.org/project/webperformancetest rather than https://openstack-browser.toolforge.org/project/933ad3ff1e264aada56e6bc3ed9e08f3. I am very used to jumping around in the tool via manually entered URLs to skip waiting for index pages to load.
Comment Actions
[22:47] < bd808> andrewbogott: I think the answer to this must be yes if you are making redundant DNS records, but to be sure: are project names guaranteed to be unique now that they are decoupled from project ids? [23:04] <andrewbogott> bd808: that's a good question! The are probably not guaranteed. [23:04] andrewbogott tries it [23:07] <andrewbogott> keystone says: "Conflict occurred attempting to store project - it is not permitted to have two projects with either the same name or same id in the same domain: name is duplicatename, project id dc28a098a38d437d925c449106139ef1. (HTTP 409) (Request-ID: req-d5b474f6-1b73-4fe1-a68e-cce8f6d76d50)" [23:07] <andrewbogott> bd808: so we're good!
Comment Actions
andrew opened https://gitlab.wikimedia.org/toolforge-repos/openstack-browser/-/merge_requests/10
Project page: Show project name up top, then ID
Comment Actions
andrew merged https://gitlab.wikimedia.org/toolforge-repos/openstack-browser/-/merge_requests/10
Project page: Show project name up top, then ID
Comment Actions
I've fixed all of the previously requested cases, but also discovered a couple more. Our hiera/enc queries are based on dicts where project ids are the dict keys. Replacing those keys with project names will fix the display but break the links (since we use project ids in urls).
Possibly the fix for this is to just to use names in the urls as well, but I'm not getting into that after dinnertime
Comment Actions
That was exhausting and non-comprehensive but I think I've replaced all the project IDs that were displaying in places that we don't want them.