[tarantool-patches] Re: [PATCH] Make `tarantoolctl start` work withiout box.cfg in init script

[Georgy Kirichenko <georgy@tarantool.org>]

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

On Monday, August 12, 2019 1:31:51 PM MSK Konstantin Osipov wrote:
> * Maxim Melentiev <m.melentiev@corp.mail.ru> [19/08/09 21:39]:
> > 1) wrapper_cfg does not override config but provides defaults,
> > overwriting only `username` and `background` options.
> 
> You can do the same with setenv.
> 
> > 2) If I get the suggestion right, suggested final solution should work
> > this way:
> > 
> > tarantoolctl start
> > 
> >   io.daemon() -- parent exits, child goes to bg
which way you suggest to use here to control execution state
> >   exec(init_script, env_with_box_cfg_overrides)
here to
> >   
> >     init_script
> >     
> >       box.cfg() -- uses overrides from env
> 
> Yes.
> 
> > tarantoolctl will always return with 0 code, no mater if there is error in
> > main script or not. Maybe it’s just wrong naming and it should be
> > `io.fork` instead, allowing parent to continue and wait for READY=1 on
> > NOTIFY_SOCKET.
> 
> No, the parent of io.daemon() can wait for the child to start.
What you mean for the word "start" - a process is created, a special event 
happened or something else?
> 
> > If it is expected to work this way
> > 
> > tarantoolctl start
> > 
> >   exec(init_script, env_with_box_cfg_overrides)
> >   
> >     if (ENV.TNT_DAEMONIZE) io.daemon() -- parent exits, child goes to bg
> >     init_script
> >     
> >       box.cfg() -- uses overrides from env
> > 
> > it also won’t show errors from child process.
> > 
> > 3) io.daemon is expected to close STD* FDs in child process, isn’t it?
> > If so - child won’t be able to show errors during startup after
> > daemonization if any. Current implementation of `tarantoolctl start`
> > shows this errors and exits with non-zero code.
> > 
> > 4) `tarantoolctl start` would exit before init_script is finished
> > (actually even before it’s started).
> > 
> > Are this incompatibilities acceptable?
> 
> No, we need to get the same semantics as your patch and we'll find
> a way to do it.

> 
> > Tarantool’s built-in toolset (tarantoolctl) does not work for app-server
> > applications but only for DB apps. The changes you’re suggesting are more
> > robust and complex, it may take significant amount of time to resolve all
> > issues and consider all details. This patch solves the problem in
> > backward-compatible way right now.
> > 
> > We would like to open-source modules which makes it much easier to use
> > tarantool as app server soon. The issue brings a limitation: “Don’t use
> > this module with tarantoolctl (because it’s buggy)”.
> Well, your patch is not good, even though it solves your issues
> now. So let's take a longer route.
The biggest issue I see we don't have any clue how to control application on 
each stage of it's life. How could application to report an error or unwanted 
state right after daemonization (or even after READY=1 written) but before 
application is really initialized. We do not have even logging here (logger is 
initialized while box.cfg fired).
I think we need a framework which allows to customize and to control 
application which includes logging and application state.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]