Hi @jonperron, I agree with your assessment of the problem. In the example given, where model_name = Xeon E5, the current implementation matches on two consumption profiles: Xeon E5, and Xeon E, and thus returns None, rather than correctly taking the exact match.

However, I'm not sure changing to exact match is the correct solution for two reasons:

1. It will create a breaking change where we alter the behavior of the code. For example, case-insensitive matching will no longer work (currently I can pass xeon gold and match the correct profile).
2. We use fuzzy matching for all other CPU-related CSV data. If we change this to be exact-match, and leave other CPU CSV lookups as fuzzy-match, we could match some properties on fuzzy-match (e.g. the die size), but get the wrong consumption profile.

Instead, I propose we modify the fuzzy matching for looking up consumption profiles to match the existing CSV fuzzy-matching we do on the cpu_specs.csv file.

This happens in the attributes_from_cpu_name function, where we have a scoring system to determine whether there is a match. In the example above, this scoring system would rate Xeon E5 as a closer match than Xeon E, and return that.

I agree with you @Shillaker, changing at one place is not the best solution. I proposed a solution which is matching the current behaviour of the API, i.e. to send only one expected result. I will look at implementing a utils function derived from the algorithm you pointed out in the attributes_from_cpu_name.

To be honest, I would rework the error handling of the API here. Indeed, it is ok, and normal, that fuzzy matching can return several results. But then, the API should return an error, or at least an indication that several values are available, rather than failing silently.

@Shillaker I thought about your proposition, and as the issue was happening with a call on /v1/component/cpu with a simple payload which did not contain the cpu name, I didn't go for it.

Instead, I kept the original fuzzy match and if multiple results were returned, I added an exact match filter (so Intel Xeon E or Intel Xeon E5 are returning the correct results, see the new tests). I didn't add an HTTP response with "multiple result returned, please precise", because it was a major breaking change in the code.