<div dir="ltr">I like #3 for windows. ("<span style="font-size:12.8000001907349px">Do nothing.") :)</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">-- dims</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 6:37 AM, Elena Ezhova <span dir="ltr"><<a href="mailto:eezhova@mirantis.com" target="_blank">eezhova@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you for bringing it up, Marian!<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 5:29 PM, mhorban <span dir="ltr"><<a href="mailto:mhorban@mirantis.com" target="_blank">mhorban@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Most of openstack services use ProcessLauncher(located in oslo.services) to run services, fork new worker processes, reload configuration, etc. Initialization of services in master process usually contains opening of sockets, so that socket will be inherited in child processes. Then master(parent) process spawns(with fork call) children. Communication between master process and children is implemented with signals, for example when master process wants to shutdown children it sends SIGTERM signal to children, to reload children config master process sends SIGHUP signal.<br>
<br>
I would like to discuss three things:<br></blockquote><div><br></div><div>The first two points also apply to ServiceLauncher which is used to start services in case a number of workers is 0 or 1:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Behaviour of reloading configuration in children processes. </blockquote><div> </div><div>If a service receives SIGHUP it is restarted which implies calling stop, reset and then start. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Additional way to control of master process.<br></blockquote><div><br></div><div> ServiceLauncher handles the same signals as ProcessLauncher.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Communication between master and children processes.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1. Behaviour of reloading configuration in children processes.<br>
Now we can reload processes by sending SIGHUP to master process. Master process reloads its own configuration and sends SIGHUP signal to children. When child process receives SIGHUP signal it loads config file, stops and starts service. During stopping-starting service new config options usually don't applied because there should be written a lot of code to manage cofiguration changes. rpodolyaka expressed idea to shutdown children during reloading configuration and respawn new workers. This approach frees us of implementing a huge amount of service-related code for reloading configuration of specific objects. Apache and NGINX uses the same reloading approach: gracefully stop children and start new child instances.<br></blockquote><div><br></div><div>From my point of view, this is a double-edged sword. On the one hand, respawning workers would indeed free us from writing reset logic for each service and save a lot of effort and time. On the other hand, the idea behind using SIGHUPs was to have an ability to make changing configuration as instantaneous and invisible to users as possible, ideally without stopping services. If we choose not to stop services at all (i.e. getting rid of calling stop and start on receiving SIGHUP) we'll be able to implement flexible configuration reloading (for example, changes to the RPC section of a config will invoke only re-initialization of RPC connections while db connections wouldn't be affected in any way).</div><div>But this approach is really quite complex so I think we have to weight the pros and cons before making a decision.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Additional way to control of master process.<br>
Right now we can control ProcessLauncher by sending signals to master process. It is the only way to manage it. The problem is that such approach is not platform independent. We already faced an issue: Windows doesn't support SIGHUP signal, so part of functionality is inaccessible in Windows :(. Usually process containers like ProcessLauncher could be managed by CLI too. What do you think about creating listening interface for incoming commands?<br></blockquote><div><br></div><div>So, the main problem here is the lack of functionality on Windows. I see several ways how to solve this problem:</div><div><br></div><div>1. Send commands to a master process like Marian suggests. As a transport we can use sockets or pipes (need to research how are pipes implemented on Windows).</div><div>2. Accept one of the signals available on Windows as SIGHUP. There are quite a few of them [1], [2] but it'll still require some research on how Windows implements signals.</div><div>3. Do nothing. The fact that oslo.service currently doesn't support SIGHUP on Windows is documented and Windows users can simply restart a service if they need to reload config files.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Communication between master and children processes.<br>
Master process uses signals to control children. Since many signals are not supported on some platforms I suggest to replace signal mechanism with pipes. Each of children will listen to input commands on one side of pipe and master process will write commands on the other side of pipe.<br></blockquote><div><br></div><div>Pipes might be a good idea, but again we shouldn't remove handlers in children at least for those signals that are supported on all platforms (SIGINT and SIGTERM). There can be situations when we need to send a termination signal to some of the workers directly.</div><div><br></div><div>Just my 2 cents :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Any idea?<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div><div class="gmail_extra">[1] <a href="https://docs.python.org/2/library/signal.html#signal.signal" target="_blank">https://docs.python.org/2/library/signal.html#signal.signal</a></div><div class="gmail_extra">[2] <a href="https://msdn.microsoft.com/en-us/library/xdkz3x12.aspx" target="_blank">https://msdn.microsoft.com/en-us/library/xdkz3x12.aspx</a></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a></div>
</div>