How it works ?
Currently slapos know two state for instance processes, started which mean that all processes will be started and stopped to stop all processes. In some cases we want to tell which processes are expected to be running on a specific instance. For example, we want to move a qemu image and we don't want to copy data when qemu is running, or some processes already EXITED (like mariadb_update) will be started every time slapgrid will reprocess the partition while this restart is not needed and usefull.
The goal now is to explain how to communicate with slapgrid to define to request a specific state for one or more instance processes. The possibility are :
- no request: if no request is donne on instance processes, slapgrid will apply the instance requested state (stated or stopped). This is the current situation.
- request started: all processes in requested state started will be started by supervisord during the next run of slapgrid. If the process is this state EXITED, he will not be started. The next run of slapgrid will start the process again.
- request stopped: all processes in this requested state will be stopped by supervisord during the next run of slapgrid. This can be used to avoid slapgrid to start some processes unless a specific action is done or a state is reached.
- request restart: all processes in this requested state will be restarted by supervisord during the next run, then the request will expired. This mean that, after the process is restarted, supervisord won't restart it unless a new restart request is done and avoid slapgrid to restart a process at every run.
If instance is stopped, then all theses previous request state will be ignored and processes will be normally stopped.
Processes request state explanation
Partition will be able to set desired processes state by generating a request file which list processes and the state that we want slapgrid to apply. This file can be created by Instance recipe or any other applications (ex: Monitor)
The request definition file
The request file is a JSON file which list of processes in their requested states, the syntax is like this:
{
"stopped": ["mariadb_update", "httpd", ...],
"restarted": ["cron", ...],
"timestamp": 123456789
}
Timestamp is used to define the validity to this request, it's required for the restarted state because it should be applied only once. To restart the process again, the timestamp need to be updated.
Removing mariadb_update from the request list will start the process, so it's not useful to specify the state started in the definition file, by default all process will be started.
How Slapgrid will manage request state file
When slapgrid will process a partition, he will read the file called .slappartXX-requested-process-state from the partition base directory which contains the JSON with list of processes to not stop or to restart, then will apply requested state. All other processes which are not in stopped or restarted state will be placed in started state (the default).
For restart state, slapgrid will check if the requested timestamp (which is mandatory for restart) is upper than the previous slapgrid execution timestamp, if true the processes can be restarted. The timestamp should ne be in the future.
To immediately apply the state in requested file, slapos bang cab be called to force reprocess the partition and let supervisord apply requested state to processes. Bang is called from recipe or other software (Monitor).
This definition file is only applied when then software instance state is started. If the instance is stopped or destroyed, this file will be ignored and all processes will be stopped.