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", ...],
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.
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.
- Allocate new SlapOS Instance from API
- Allocate new SlapOS Instance from web UI
- ERP5 UNG
- SlapOS Master
- Deploy SlapOS Master
- Add promises to Software Release
- Allow use of Virtual Machines on your Node
- Customize a SlapOS Profile
- Customize SlapOS For PHP Application
- SlapOS use request with Wordpress
- Setup ERP5 in VIFIB PaaS
- How to write Instance profile
- Erp5TestNode with Slapos
- Order and access a WebRunner on VIFIB
- Start an empty HTML5 project in Web Runner
- SlapOS Client
- Installing SlapOS Package
- Installing SlapOS Slave Node
- Installing SlapOS USB Key
- Installing SlapOS on a Virtual Machine
- Installing SlapOS Node on Windows
- Installing SlapOS Slave Node
- KVM: Windows Guest
- ERP5 Performance Testing
- ERP5 Practical Scalability Testing
- Registering with old login
- Running SlapOS
- SlapOS Request Method
- Web Runner Request ERP5
- Running SlapOS
- SlapOS Node Internals Explained
- Define partition processes state in SlapOS
- mutliple storage with SlapoS
- SlapOS prerm scripts
- Setup a static website in VIFIB PaaS