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?
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
