You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Discussed in PR #1712 - the AbstractScriptSession does not really use the cache directory to advantage. It deletes the data, never preserving it run to run.
We may be able to introduce an "instance-id" concept that allows for the safer segmentation of cache (or other data) that the application may want to store, so that we don't have to rely on an app creating its own random number. The end user would have a bit more control over when "instance-id"s get reset.
In the case of a container, by default we'd write down a random instance-id on first startup into the container's writable layer, and configure the application to read that location on startup, preserving the instance-id across container restarts, but not across container re-creations. If the application runner wanted to, they could elevate the instance-id to a more stable location (or, explicitly set the instance-id) to preserve the instance-id across container re-creations.
In the native case, we'd likely want a random instance-id on each startup until the application runner can configure a more stable instance-id, implying their own semantics on 'instances'.
The text was updated successfully, but these errors were encountered:
Discussed in PR #1712 - the AbstractScriptSession does not really use the cache directory to advantage. It deletes the data, never preserving it run to run.
We may be able to introduce an "instance-id" concept that allows for the safer segmentation of cache (or other data) that the application may want to store, so that we don't have to rely on an app creating its own random number. The end user would have a bit more control over when "instance-id"s get reset.
In the case of a container, by default we'd write down a random instance-id on first startup into the container's writable layer, and configure the application to read that location on startup, preserving the instance-id across container restarts, but not across container re-creations. If the application runner wanted to, they could elevate the instance-id to a more stable location (or, explicitly set the instance-id) to preserve the instance-id across container re-creations.
In the native case, we'd likely want a random instance-id on each startup until the application runner can configure a more stable instance-id, implying their own semantics on 'instances'.
The text was updated successfully, but these errors were encountered: