Proposed Queue Names

[rsandor]

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:

• container
• dock (or docker, 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

[anandkumarpatel]

is cluster-provision the correct format in this new scheme?
and a new event org-whitelisted would also be correct in this scheme right?

[anandkumarpatel]

(comment got deleted?) hmm to me docker means actual deamon, and dock means the server we should use them as such

[tjmehta]

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

[anandkumarpatel]

would it be better to use a different character between consumer and queue name? so its easy to see which is the consumer

[tjmehta]

maybe, but it should always be the first

[anandkumarpatel]

how I think fanout should work for consumers of same name queue

[rsandor]

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.

[rsandor]

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?

[anandkumarpatel]

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)