Message queue multi-tenancy

[somayeh-najafi]

Considering different instances of Master node, do we need to have other KubeMQ queues or we can use the same existing queue?

What would be our approach regarding other instances of Quartermaster?

[marcomicera]

If we use the official KubeMQ YAML file, it'll be deployed in a dedicated namespace.

The documentation says that:

Channels names can be separated by the . symbol to create messaging stream hierarchies.

Proposal

Quartermaster ID.Direction.Phase.Module name, with:

• QuartermasterID: a Quartermaster instance identifier.
• Direction: {request | reply}, requests being commands imposed by the master to modules, reply-ies being results sent from modules back to the master.
• Phase: {build | analyze | report}, one of the Quartermaster phases. init might be added if needed.
• Module name: a module ID, e.g., mvn for the Java builder (build phase), scancode for the Scancode reporter (report phase), etc.

Benefits

• The QuartermasterID would allow us to use the same KubeMQ instance for different Quartermaster instances. It's something that we would need for database multitenancy either way.
• We can query messages using wildcards. We don't know yet whether we will need some kind of entity that will need to be able to consume different kinds of events.