Service instance storage and service instance state
Service storage
Aos Communication Manager (CM) provides persistent storage for AosEdge services in order to store any persistent information. Storage folders are located separately (<working_dir>/storages) from the service image in order to keep the storage between service updates. Each service instance has its own storage folder. When service is removed for the current subject, its storage folder is removed too. The size of service storage is limited by and Service provided in the service configuration file.
In order to use service storage, disk quotas should be enabled on the <working_dir> disk partition. See Implementing Disk Quotas on Linux as an example of how to enable disk quotas.
Disk quotas limit disk usage with FS block size granularity. For more precise limitations we should format <working_dir> disk partition with 1K block size.
On service install, launcher checks if service storage is enabled and sets a disk quota for the service user. Then, before each service starts, launcher updates config.json in order to mount the storage folder according to the user claim. If a service instance is launched on the same node ad CM storage provides as an absolute path. In case of a service instance running on the remote node storage provides as NFS path.
Service state
In order to handle the service settings, AosEdge provides a state mechanism. The state is data that can be updated from AosCloud or locally by the service itself. The state data is stored in the service storage folder as the state.dat file. The state file size is limited by (resource management)[doc/resource_management.md].
The state can be updated from AosCloud with an update state message. If the state is changed locally by the service, SM should upload it to AosCloud with a new state message. SM also may request the last valid or default service state from AosCloud by sending a state request message (currently this scenario is not implemented TBD).
launcher watches for each running service state file and, in case it is changed, sends a new state request to the cloud. As the file may be written by chunks, launcher starts a special watch timer (1 sec) once change is detected. The new state is sent when there is no other change during the timer interval.
If AosCloud rejects a new state, launcher sends a state request to get the last valid service state.
launcher stores checksum of each successfully updated state. If, on service start, launcher detects wrong state checksum, it treats this state as corrupted and sends state request to the cloud.