reload and check logical in arbiter

[andyxning]

i found that no matter what reload(without -v) or check(-v) is specified with shinken-arbiter, we just do the is-correct check, this may be useless and may make the reload take more time.

I think we can add a more option with shinken-arbiter -i, i.e., ignore check. By default we can use the is_correct function to check if the configuration is right. But if we can make sure that the configuration is already checked and everything is fine, we can explicitly add the -i option to bypass the check logic which has already been done with -v options.

[naparuba]

Object check do not take lot of time as far as I remeber. Please give use
hints about how much time we can save here by skipping this phase on a
normal launch after a manual check.

On Sat, Mar 21, 2015 at 7:05 AM, Ning Xie notifications@github.com wrote:

i found that no matter what reload(without -v) or check(-v) is specified
with shinken-arbiter, we just do the is-correct
https://github.com/naparuba/shinken/blob/master/shinken/daemons/arbiterdaemon.py#L446
check, this may be useless and may make the reload take more time.

I think we can add a more option with shinken-arbiter -i, i.e., ignore
check. By default we can use the is_correct function to check if the
configuration is right. But if we can make sure that the configuration is
already checked and everything is fine, we can explicitly add the -i
option to bypass the check logic which has already been done with -v
options.

—
Reply to this email directly or view it on GitHub
#1545.

[geektophe]

I agree with @naparuba, the check phase is negligible in regard to the parse phase, which is anyway mandatory. In addition, even if the I could, personaly I would not take the risk to send a configuration which has not been verified before.

What could be done to optimize restart time could be to reload the configuration from the arbiter process itself on the HUP signal, and if it's correct, replace the existing one. This could avoid having to restart the process, and perform a double check.

[andyxning]

i agree with @Christophe Simon, that we should take consider to make HUP
signal handler available on arbiter and in that case without restart the
arbiter process we can have arbiter to process external commands with no
lose and still do other works.

++++++
Ning Xie

2015-03-27 2:18 GMT+08:00 Christophe Simon notifications@github.com:

I agree with @naparuba https://github.com/naparuba, the check phase is
negligible in regard to the parse phase, which is anyway mandatory. In
addition, even if the I could, personaly I would not take the risk to send
a configuration which has not been verified before.

What could be done to optimize restart time could be to reload the
configuration from the arbiter process itself on the HUP signal, and if
it's correct, replace the existing one. This could avoid having to restart
the process, and perform a double check.

—
Reply to this email directly or view it on GitHub
#1545 (comment).

[geektophe]

I'll have a look at that.

[andyxning]

Can we just make this Reload configuration without stop Arbiter daemon as a main feature in Shinken 2.6. I think it is really useful and essential

[naparuba]

Yes, if the new arbiter is start with the -r parameter, it will kill the
old one after loading and parsing all elements, so the huge part. That
can make the old arbiter alive for longer period and less "no arbiter" time
:)

On Thu, Apr 23, 2015 at 5:58 AM, Ning Xie notifications@github.com wrote:

Can we just make this Reload configuration without stop Arbiter daemon
as a main feature in Shinken 2.6. I think it is really useful and essential

—
Reply to this email directly or view it on GitHub
#1545 (comment).

[andyxning]

That's very great and i am looking for that feature.

And do we have beginning to do this in master branch? if we have any code already carrying on, i hope you can give me a place to see it.

++++++
Ning Xie

2015-04-23 14:44 GMT+08:00 Gabès Jean notifications@github.com:

Yes, if the new arbiter is start with the -r parameter, it will kill the
old one after loading and parsing all elements, so the huge part. That
can make the old arbiter alive for longer period and less "no arbiter" time
:)

On Thu, Apr 23, 2015 at 5:58 AM, Ning Xie notifications@github.com
wrote:

Can we just make this Reload configuration without stop Arbiter daemon
as a main feature in Shinken 2.6. I think it is really useful and
essential

—
Reply to this email directly or view it on GitHub
#1545 (comment).

—
Reply to this email directly or view it on GitHub
#1545 (comment).