Along the same lines as my other comment, I don't think the platform should have any knowledge or handling of the report format, it's why we left it so open-ended in the contract with the profiler.

What I'd rather see is us take an override_config parameter. The paradigm there is that the user can shove anything he wants into that, he just has to know what the plugin will look for. That config parameter is set in the PluginCallConfiguration that's passed to the profiler during the call (side note, that format is incorrect, I'll comment on that line of code later). Set the override_config value in the PluginCallConfiguration to what's passed here and the profiler accesses it through the normal .get() call.

That will let the user pass whatever it needs to. In our immediate case, that's telling the RPM Profiler it wants the report errata-centric or consumer-centric. In the near future, we'll add config values to that so the user can pass in pagination values to limit how many are returned.