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 :
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.
Good improvement over the first version, still some work to do to have it really look good. Keep it up!
No need for this monitoring_stack: Stack field for now. This is a case of YAGNI. We support only one type and I don't see in the very short term a use case that would force us.
What about path, path_type and namespace? These certainly don't support any String?
861f266c4e
Merge pull request 'feat: LAMP stack and Monitoring stack now work on OKD, we just have to manually set a few serviceaccounts to privileged scc until we find a better solution' (#36) from feat/lampOKD into master
51724d0e55
feat: LAMP stack and Monitoring stack now work on OKD, we just have to manually set a few serviceaccounts to privileged scc until we find a better solution