Motivation
When running the bot on a Raspberry Pi with a read-only root filesystem (e.g. raspi-config overlay or similar), the default setup is awkward: main.py expects a writable DATA_DIR for SQLite (user_prefs, user_cmds, node_db), node_info.json load/save, and optional failed-packet dumps.
In that deployment, the bot is effectively a gateway: forward packets (and related telemetry) into the Meshflow API. Anything stored locally can be ephemeral—it does not need to survive reboot.
Current behavior (summary)
DATA_DIR is created and used for three SQLite databases and JSON round-trips for InMemoryNodeInfoStore.
StorageAPIWrapper can already skip disk on API errors if failed_packets_dir is None.
- Optional packet JSON dumps only occur when
DUMP_PACKETS_PORTNUMS is set.
- Runtime behavior already includes
InMemoryNodeDB in tests; production main always wires SqliteNodeDB.
Proposed feature
Add a first-class ephemeral / read-only mode (name TBD), e.g. env var EPHEMERAL=1 or READONLY_FS=1, that:
- Uses
InMemoryNodeDB instead of SQLite for node cache (acceptable tradeoff: empty after restart until traffic is seen).
- Uses no-op or in-memory
AbstractCommandLogger and AbstractUserPrefsPersistence so admin history and prefs are not persisted (or document that admins should use tmpfs if they want SQLite until reboot).
- Skips
node_info.json load/save (or no-ops) so shutdown does not require a writable path.
- Passes
failed_packets_dir=None to StorageAPIWrapper so failed uploads are not written to disk.
- Does not call
os.makedirs for a persistent data directory when nothing needs it—or documents DATA_DIR on tmpfs as the supported path for users who still want SQLite until reboot without code changes.
Acceptance criteria (suggested)
Workaround today
Point DATA_DIR at tmpfs (e.g. under /run or /tmp) so SQLite and JSON work on a volatile filesystem; optionally patch main to pass failed_packets_dir=None. This issue asks for built-in support so operators do not need a fork or manual wiring.
Related context: packet ingestion does not inherently require SQLite; local DBs mainly support commands, !nodes, prefs, and admin history.
Motivation
When running the bot on a Raspberry Pi with a read-only root filesystem (e.g.
raspi-configoverlay or similar), the default setup is awkward:main.pyexpects a writableDATA_DIRfor SQLite (user_prefs,user_cmds,node_db),node_info.jsonload/save, and optional failed-packet dumps.In that deployment, the bot is effectively a gateway: forward packets (and related telemetry) into the Meshflow API. Anything stored locally can be ephemeral—it does not need to survive reboot.
Current behavior (summary)
DATA_DIRis created and used for three SQLite databases and JSON round-trips forInMemoryNodeInfoStore.StorageAPIWrappercan already skip disk on API errors iffailed_packets_dirisNone.DUMP_PACKETS_PORTNUMSis set.InMemoryNodeDBin tests; productionmainalways wiresSqliteNodeDB.Proposed feature
Add a first-class ephemeral / read-only mode (name TBD), e.g. env var
EPHEMERAL=1orREADONLY_FS=1, that:InMemoryNodeDBinstead of SQLite for node cache (acceptable tradeoff: empty after restart until traffic is seen).AbstractCommandLoggerandAbstractUserPrefsPersistenceso admin history and prefs are not persisted (or document that admins should use tmpfs if they want SQLite until reboot).node_info.jsonload/save (or no-ops) so shutdown does not require a writable path.failed_packets_dir=NonetoStorageAPIWrapperso failed uploads are not written to disk.os.makedirsfor a persistent data directory when nothing needs it—or documentsDATA_DIRon tmpfs as the supported path for users who still want SQLite until reboot without code changes.Acceptance criteria (suggested)
README/.env.examplewith a short Raspberry Pi + overlay note.Workaround today
Point
DATA_DIRat tmpfs (e.g. under/runor/tmp) so SQLite and JSON work on a volatile filesystem; optionally patchmainto passfailed_packets_dir=None. This issue asks for built-in support so operators do not need a fork or manual wiring.Related context: packet ingestion does not inherently require SQLite; local DBs mainly support commands,
!nodes, prefs, and admin history.