Code review comment for lp://qastaging/~thomir-deactivatedaccount/core-result-checker/ci-result-checker-config

If the goal is to have a result-checker for each 'service-set' [1], then I think this actually means deploying each result-checker with it's own mojo spec. There is then a 1:1 mapping of spec to configuration which I feel is one of the primary purposes that mojo was built to solve. For example if IS is deploying a blog for two different organizations, they would not use a single mojo spec and just change the config to give the blogs different names, they would set this up as distinct mojo specs. Also, if we were to hand off this selftest service-set to a different team to own, they would need that distinct mojo spec to properly own it.

I am in favor of pulling out these queue naming details into the configuration. IFF the difference between two deployments is the name of a few variables but they perform the exact same logic then it makes sense to keep them cohesive through a common code base. I would even take this a step further and just deploy a single result checker for everything, but the design does not support that (yet).

[1] 'service-set' - I'm trying to come up with a term that allows us to talk about all of the deployed micro-services that make up a usable thing. Suggestions welcome.