Proposed Queue Names
rsandor opened this issue · 9 comments
Naming Convention
It's very simple, do what we normally do when we program:
{namespace[1]}-{namespace[2]}-...-{(re)action}
(Namespaces should be general to the left, and specific to the right).
Proposed Queue Names
Use two top-level namespaces:
containerdock(ordocker, still not sure which I prefer)
Here's how we'd name the queues using this convention:
| New Name | Old Name |
|---|---|
container-image-builder-create |
create-image-builder-container |
container-instance-create |
create-instance-container |
container-instance-delete |
delete-instance |
container-inspect |
inspect-container |
container-image-builder-started |
on-create-start-image-builder-container |
dock-removed |
on-dock-removed |
dock-unhealthy |
on-dock-unhealthy |
container-image-builder-created |
on-image-builder-container-create |
container-image-builder-died |
on-image-builder-container-die |
container-image-builder-started |
on-image-builder-container-start |
container-instance-created |
on-instance-container-create |
container-instance-died |
on-instance-container-die |
container-instance-started |
on-instance-container-start |
container-restarted |
restart-container |
container-instance-started |
start-instance-container |
container-instance-stopped |
stop-instance-container |
is cluster-provision the correct format in this new scheme?
and a new event org-whitelisted would also be correct in this scheme right?
(comment got deleted?) hmm to me docker means actual deamon, and dock means the server we should use them as such
what about something like:
<consumer>:<namespace1>:<namespace2>:...:<event>
| New Name | Old Name |
|---|---|
api:container:image-builder:create |
create-image-builder-container |
api:container:instance:create |
create-instance-container |
api:container:instance:delete |
delete-instance |
api:container:instance:inspect |
inspect-container |
api:container:image-builder:started |
on-create-start-image-builder-container |
<consumer>:dock:removed |
on-dock-removed |
<consumer>:dock:unhealthy |
on-dock-unhealthy |
api:container:image-builder:created |
on-image-builder-container-create |
api:container:image-builder:died |
on-image-builder-container-die |
api:container:image-builder:started |
on-image-builder-container-start |
api:container:instance:created |
on-instance-container-create |
api:container:instance:died |
on-instance-container-die |
api:container:instance:started |
on-instance-container-start |
api:container:instance:restart |
restart-container |
api:container:instance:start |
start-instance-container |
api:container:instance:stop |
stop-instance-container |
EDIT:: or maybe single word event names are too general.
Here is another option
| New Name | Old Name |
|---|---|
api:image-builder:container-create |
create-image-builder-container |
api:instance:container-create |
create-instance-container |
api:instance:container-delete |
delete-instance |
api:instance:container-inspect |
inspect-container |
api:context-version:container-started |
on-create-start-image-builder-container |
<consumer>:dock:removed |
on-dock-removed |
<consumer>:dock:unhealthy |
on-dock-unhealthy |
api:context-version:container-created |
on-image-builder-container-create |
api:context-version:container-died |
on-image-builder-container-die |
api:context-version:container-started |
on-image-builder-container-start |
api:instance:container-created |
on-instance-container-create |
api:instance:container-died |
on-instance-container-die |
api:instance:container-started |
on-instance-container-start |
api:instance:container-restart |
restart-container |
api:instance:container-start |
start-instance-container |
api:instance:container-stop |
stop-instance-container |
would it be better to use a different character between consumer and queue name? so its easy to see which is the consumer
maybe, but it should always be the first
how I think fanout should work for consumers of same name queue
Yeah I think this is parallel to how we are thinking of renaming worker-specific events. And for what we have at the moment it will work just fine. For instance, when an organization is whitelisted we do the following from API:
PUBLISH shiva:cluster:provision { githubId: 12345 }
Imagine, we need now to also e-mail the client and setup some initial state in Magus (or something) in response to the same event. This would change to the following model in API:
PUBLISH org:whitelist { githubId: 12345} }
FAN org:whitelist TO
shiva:cluster:provision { ... }
magus:do:something { ... }
email:notify:customer { ... }
END
Over time this can be taken even further with individualized fans for each of the subsystems involved. I think the right course of action is to implement this when we need it. While it will require a little more work than if we already setup the queue to do this, it allows us to avoid premature abstraction.
Also worth noting from the RabbitMQ documentation:
The core idea in the messaging model in RabbitMQ is that the producer never sends any messages directly to a queue... the producer can only send messages to an exchange.
This is a best practice that suggests we should design our applications to use to the exchange model up-front. Perhaps my fear of premature abstraction are unfounded?
yea, I think we should start with this mentality now, otherwise we will not move the the other paradigm.
messages should be emit'ed and then consumers will come along when they are needed.
shiva:org:whitlisted { ... }
magus:org:whitlisted { ... }
email:org:whitlisted { ... }
its one of the core principles of event driven, reactive architecture. (which I want runnable to be one day)