Open Stack

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.

I would like to discuss three things:
1. Behaviour of reloading configuration in children processes.
2. Additional way to control of master process.
3. Communication between master and children processes.

1. Behaviour of reloading configuration in children processes.
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.

2. Additional way to control of master process.
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?

3. Сommunication between master and children processes.
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.

Any idea?