Potential for Optimization

Code in question is: openstack_database_exporter/internal/collector/cinder/limits.go

Specifically, this loop here, I omit some code to make it clearer:

for projectID, projectName := range allProjectIDs {
    ...
    for _, vt := range volumeTypes {
    			vtName := vt.Name.String
    			perTypeResource := "gigabytes_" + vtName
    			perTypeLimit := int32(-1) // default
    			for _, quota := range quotaLimits {
    				if quota.ProjectID.String == projectID && quota.Resource == perTypeResource {
    					perTypeLimit = quota.HardLimit.Int32
    					break
    				}
    			}
...

If allProjectIDs and quotaLimits contain many entries, this can grow quickly. It is noteworthy that if a project is deleted on keystone, it is not necessarily deleted in cinder. See: Archived thread

Quote from Stephen:
As a general observation, one of the many downsides of service-specific quotas
(as opposed to keystone-managed "limits") is that if/when a project is deleted
in keystone, quotas related to that project can be left hanging around in
various services

An alternative would be use a hash map, for example something that uses quota.projectID and quota.Resource as key and returns the quota.HardLimit as value. So you iterate over quotas and projects only once. Speed up would be $\text{O}(mn) \rightarrow \text{O}(n+m)$

Start in internal/collector/cinder/limits.go around line 231 and trace how allProjectIDs, volumeTypes, and quotaLimits are populated. Replace the repeated quota search with a keyed lookup while preserving default limits and handling quotas left behind for deleted projects. Done means the exporter produces the same limits with lookup work reduced from O(mn) to O(n+m).