Enable users to configure location of tedge-agent current operation state folder (.agent)

[reubenmiller]

Is your feature request related to a problem? Please describe.

Doing firmware updates requires certain tedge-agent state to be persisted across partition swaps in order for the agent to know that it was in the middle of processing a firmware update operation (even before any kind of restore backup state can be executed).

This "current operation" state is stored in the /etc/tedge/.agent folder.

Describe the solution you'd like

Make the /etc/tedge/.agent folder configurable via the tedge.toml.

Below shows an example of the desired tedge.toml setting.

file: /etc/tedge/tedge.toml

agent.state.path = "/data/tedge/.agent"

Another slight variant of the above value would be to have a configurable fallback settings, which

agent.state.persistent.path = "/data/tedge/.agent"

On startup, the tedge-agent would check if the persistent folder exists and if it does use that folder, otherwise use the default /etc/tedge/.agent (e.g. the path controlled via the --config-dir flag of the tedge-agent)

STATE_DIR=/etc/tedge/.agent
IF PATH_EXISTS(get_value(agent.state.persistent.path)) THEN
    STATE_DIR = get_value(agent.state.persistent.path)
END

The later would have the advantage that this setting would be baked into the defaults of the thin-edge.io agent making it slightly less open to misconfiguration, as the value has a sensible default value, where the behaviour can be modified by just creating the folder at /data/tedge/.agent (for example). Other misconfigurations would be very easy as the user could be changing some other settings in the tedge.toml file during the build process, and this would result in the firmware operation not resuming after a partition swap (with no possibility of a rollback happening without the assistance of an independent rollback service)

Notes

• For this to work the agent.state.path value needs to be set both before and after the firmware update. In practice this value will part of the initial firmware (OS) image and included in all subsequent firmware (OS) images, otherwise it will not work.

Describe alternatives you've considered

The current workaround is to configure the /etc/tedge/.agent folder to be a symlink to /data/tedge/.agent (where the /data is mounted to a persisted partition which is available from both A/B partitions). A symlink is hard to maintain as it also has to be based up in order to preserve it across firmware updates, and this is even more complicated to manage since the folder is mixed in with other important settings under the /etc/tedge/ folder (e.g. operation definitions, child device info, sm-plugins etc.)

Another solution to storing the whole /etc/tedge folder under /data/tedge, however this would present many problems for additional tooling which expects that the agent config is always stored under /etc/tedge. Technically this folder is configurable, but only via command line options (--config-dir <dir>), however there is no way to set this globally so that all thin-edge.io components use the same directory, and there is no clear way to communicate to other 3rd party components that the folder is located elsewhere (e.g. how does the user know where to put the operations and sm-plugins (as these are part of the public thin-edge.io interface)?)

Additional context

[didier-wenzek]

What has been finally implemented (by #2492):

• A new tedge-config setting has been added: agent.state.path
• This path is used to store the tedge-agent state across restarts
  • currently two files are stored there restart-current-operation and software-current-operation
  • restart-current-operation is created when a device restart is requested
  • software-current-operation is created either when a software update or list is requested.
• If for some reasons this directory cannot be used (doesn't exist or is not writable),
  then the tedge-agent use /etc/tedge/.agent as a fallback.
• The default value for agent.state.path is /data/tedge/agent.

[gligorisaev]

QA has thoroughly checked the feature and here are the results:

• Test for ticket exists in the test suite.
• QA has tested the function and it's functioning according description.