Closed masci closed 2 weeks ago
Hmm, this makes sense. Trying to understand the hierarchy of control now
* task definitions have an `agent_id` specifying what service to send to (this probably needs to be renamed in the future)
Correct, this didn't change.
* messages have a `type` used for judging how a service handles a message
Same as before
* the `topic` for a consumer is defined by the control plane config topic + msg type?
Correct, this is brand new
* does this mean each service + message type combination has its own topic/queue now?
Exactly, which makes it possible to share the same Kafka cluster (but really any message queue broker) across multiple control planes
Slightly fuzzy if there's anything beyond this ๐ I feel like I need to draw this out now
That's really it :)
@masci thanks for confirming!
Follow up issues:
Apologies for the mega-refactoring, breaking this down into smaller PR would take a week ๐
Fixes #349 for good.
Problem
Message publishers and subcribers assumed the "topic" to listen to was the same as the message type. This works in a single-tenant environment but becomes a problem when the same message queue holds data for multiple control planes and services, causing clashes.
Solution
control_plane_one.my_service
so that services with the same name attached to different control planes can coexistFollow up