Acceptable solution for tenant names

[na50r]

I noticed that there are many metrics where the tenant name were still missing. It is possible to import keystonedb and get the tenant name by tenant id but making a query each time for this seems inefficient. I tried out two solutions and both work.

Main solutions: Create a hash map of tenant id to tenant name once and then re-use it.

Solution 1: Wrapper around the Registry
Before placing the registry in promhttp.HandlerFor, use a wrapper to iterate over all labels and if tenant id is present, add a tenant name label. This works but may be an overkill. It creates metrics that were never present in Niedbalski exporter. Too many labels will not break a monitoring setup but feels excessive. Code changes are limited since we only touch one or two files (main.go and collector.go for example)

Solution 2: Global accessible hash map
You can use the util package or create special package where a hash map is initialized. Initialize the hash map right before starting the listener, so it is run only once. The collectors can then access that variable by importing the package, util.TenantMap and you can set the tenant name everywhere you like. This requires code changes at multiple places, namely everywhere were Niedbalski and co. decided to add tenant names but feels like the appropriate solution. This idea can be also used for other metrics where we require data involving multiple dbs. I prefer this solution.

[mnaser]

I think the goal is to bring back the tenant name once we have proper coverage and connectivity to Keystone, then we can pass that in to grab that.

The challenge is how to do it efficiently since we can't do cross database joins.

[na50r]

The challenge is how to do it efficiently since we can't do cross database joins.

Yes, the 2nd Solution avoids joins but you need to ensure that Keystone is connected and Keystone will be queried twice; once to store a hashmap in memory and once again to export Keystone metrics. Of course, it also begs the question if this would scale when the project count increases, we cannot store everything in memory.