Intial worker sync should be done via RabbitMQ & not via a direct connection to MongoDB about worker HOT 4 CLOSED

Could instead have the worker hit an API endpoint for that config.

from worker.

There are 2 reasons I think using RabbitMQ will be preferable over polling the API:

• Polling the API requires having it accessible to all workers in addition to RabbitMQ, this adds complexity to setting up workers & security wise increases the possible attack surface (as the entire architecture of Nebula revolves around RabbitMQ removing that instead would be near impossible)
• Polling the API adds a risk of a "roaring horde" problem if\when a lot of workers attempt to do the initial sync at the same time, the current workaround of having a random delay before syncing will solve that with the API but as RabbitMQ can simply queue massages & reply to them in order it removes the need of that random delay which should help speed up the initial sync.

That been said I'm a strong believer in letting the end user choose how to configure his\hers tools and adding an optional envvar\config-setting which allows the workers to query via the API rather then through RabbitMQ won't be that much of work (in fact there is already an API endpoint which returns the config of an app) so why not have both?

@nochte feel like raising a ticket request about it?

from worker.

Attached is the planned worker "bootstraping" workflow for resolving this ticket via RabbitMQ direct reply RPC calls, after a lot of thoughts and discussions with multiple knowledgeable people this feels to me like the best course of action as it both allows the flexibility of AMQP will still remaining simple to implement in a scalable fashion.

from worker.

Pushed to latest\master, will be added to next numbered release (which due to the major architectural change will be a Major release to v2.0.0).

from worker.