I like this solution for now, I think the best solution would be a dedicated cluster per tenant but it makes sense why we can't. I think the proposed solution works for our current scale.…
You missed the point of using a trait here. See my comment and refactor accordingly.
This defeats the purpose of using a trait. Also prevents extensibility by external users of Harmony.
I feel like this should not be public. Our public APIs should go through Scores, Topologies and Inventories. What's the reasonning here?
It's exposed through the score, and if a score…
I feel like this should not be public. Our public APIs should go through Scores, Topologies and Inventories. What's the reasonning here?
Since we're supporting a list, shouldn't we use filter_map instead so we can handle all the instances at once?
Yeah, these two functions here discord_alert_builder and slack_alert_builder here should be implementations of a trait.
The name MonitoringAlertingStackScore bothered me all along but I couldn't figure out why. Now I did :
Good improvement over the first version, still some work to do to have it really look good. Keep it up!
What is service_name used for? As this is user facing, a bit of rust doc (with triple slashes ///) to describe how to use would be useful here.
Nice, but did you test smtp? If it's not working yet there should be a // TODO comment or something like that.
Why use values_overrides here when there already is a values_yaml right above? Would make it a lot more readable I think.