Add --run-worker to distinguish it from running without supervisor

[naritta]

This fixes #1027

・We have to distinguish running only worker without supervisor from running worker under supervisor, because when using only worker, we have to create socket manager in worker.

・If we fix not to use socket manager when --no-supervisor, we have to fix plugin side, then the point to fix will increase. So I fixed supervisor side.

[tagomoris]

I want just to correct my idea:

• normally, Fluentd's worker process will work with supervisor including ServerEngine instance, and it (supervisor) provides SocketManager
• now Fluentd supervisor process executes workers with --no-supervisor option
• plugins always use SocketManager API, and it's required for multi-process support (in future)
• If users apply --no-supervisor option by themselves, Fluentd doesn't setup SocketManager in worker processes. It breaks plugin's behavior.

Your change will do:

• add another option --run-worker to use it from supervisor process to run workers without setup of SocketManager
• fix worker behavior with --no-supervisor to setup SocketManager to pass it to plugins

Is it right?

[naritta]

Thank you for summarizing. It's right.

[tagomoris]

Great.
I think these situation is a bit complex and difficult to understand, so we need to add these details as code comment in supervisor.rb. @naritta could you add them?

In addition to it, we should take care about naming of command line options and these descriptions.
There are 3 mode to launch Fluentd:

• launch Fluentd supervisor: without any options
• launch Fluentd worker only, without supervisor: --no-supervisor
• launch Fluentd workers under supervisor (launched by supervisor): --run-worker?, --under-supervisor?

IMO it's more understandable to name the new option as --xxx-supervisor by comparing existing --no-supervisor.
Moreover, it's better to describe explicitly that "this option is NOT for users" on that option to help users not to try using them.

[tagomoris]

@naritta ping? May I add fixes on this change?

[naritta]

@tagomoris Sorry, I'll fix now. Could you wait a little?

[naritta]

Sorry to be late. Could you review when you have time?

[tagomoris]

IMO worker_with_supervisor still looks curious. In default, worker runs under supervisor, but worker_with_supervisor 's default value is false.

I think that variable (state) should be a something to be turned into true when --no-supervisor is specified.
I propose that:

• rename it as standalone_worker with default value false
• turn it true only when --no-supervisor specified
• call create_socket_manager if @standalone_worker is true

@naritta How do you think about this?

[naritta]

@tagomoris Thank you for reviewing. I think so, too.
I fixed it and could you review when you have time?

[tagomoris]

Code looks good to me. I'll merge this after confirmed CI green.

[tagomoris]

Merged.

[naritta]

Thank you very much for reviewing.