eds-inventory

ADR-0001: Go Services and a SQLite Store

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0001: The Services Are Go, and the Inventory Is Kept in SQLite, with No cgo


Status	Accepted 2026-10-24
Date	2026-10-24
Scope	The language of eds-inventory’s services, and the database the inventory is kept in. Not how sources are matched to one another, which is later.

Context

The inventory needs a store from its first slice, the owner’s iTunes library. It holds one owner’s music: a few thousand albums, not millions. It runs in EdS’s tenant, where EdS’s back end may run on one Pi or several (EdS ADR-0033), so whatever it is made of must run there.

Change Record Template (CHG)

Mon, 01 Jan 0001 00:00:00 +0000

Change Record Template (CHG)

The shape every change record takes. Copy the skeleton into a new file, fill it in before the change runs, and complete Outcome after.

It follows Deevnet IoTaaS’s template, trimmed to what an application needs: no site or maintenance window, because eds-inventory changes one tenant.

Where it goes


Number	The next unused `CHG-NNNN`, in the order records are opened. Runs across years, never reused, and kept even if the change is abandoned.
File	`docs/content/docs/changes/<YYYY>/<NNNN>-<slug>.md`
Title	`CHG-NNNN: <What changed>`, from the point of view of what is running
Date	The day execution starts. While it is still planned, the planned date; with none yet, Unscheduled
Weight	`NNNN`, so records sort by number
Index	Add a row to Change Records and to that year’s page

Status

Planned → In progress → Complete, or Rolled back or Abandoned. A record is never deleted: a change that was abandoned or rolled back is exactly the one worth keeping.

CHG-0001: inventoryd on EdS's Workload

Mon, 01 Jan 0001 00:00:00 +0000

CHG-0001: inventoryd on EdS’s Services Workload, with the Owner’s iTunes Library


Date	2026-10-24
Change type	Deployment
Status	Complete 2026-10-24
Systems	EdS’s services workload (`services.eds.mobile.deevnet.net`): the image `localhost/eds-inventory`, `eds-inventory.service`, `/var/lib/eds-inventory`
How	`make -C deploy image load WHERE=builder`, `make -C deploy unit`, `make -C deploy library XML=…`
Risk	Low. Nothing running asks it until EdS’s voiced is pointed at it (EdS CHG-0041). Most likely to go wrong: the Builder’s first build of the image
Decisions	ADR-0001, ADR-0002, ADR-0003
Related	EdS CHG-0041, which points voiced at it

Summary

The first deployment of eds-inventory: inventoryd onto EdS’s services workload, answering on 127.0.0.1:8740, with the owner’s iTunes library collected into it.

Sources, Store and Clients

Mon, 01 Jan 0001 00:00:00 +0000

Sources, Store and Clients

A first picture, drawn before anything is built. It shows the shape the requirements so far describe, and will change as they settle.

Sources

Where the owner’s music is kept today. Each stays the truth for what it holds.

ADR-0002: The iTunes Library Is Collected from Its XML

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0002: The iTunes Library Is Collected from Its XML, and Asked for by Nearest Name


Status	Accepted 2026-10-24
Date	2026-10-24
Scope	The first source, the owner’s iTunes library: how it is read, how its albums are kept, and the first version of the contract that answers for it. Not how the XML reaches the inventory, which waits on where the inventory runs.
Takes over	EdS ADR-0046, whose index of the library this replaces

Context

EdS’s voiced matches spoken requests against an index of the owner’s iTunes library: library.json, made by EdS from the XML iTunes writes and copied to voiced by hand (EdS ADR-0046). It asks four things of it: the artist nearest a name, the album nearest a title, the first of several titles the library has, and an artist’s own albums by year. That index is an inventory concern living in EdS.

Database Schema

Mon, 01 Jan 0001 00:00:00 +0000

Database Schema

The inventory’s database, as internal/store creates it: SQLite, schema version 1 (kept in PRAGMA user_version). Nothing but internal/store reads or writes it (ADR-0001).

This schema is being reworked; the changes agreed so far are on Proposed Schema, and this page stays what runs until they are built.

An album is the inventory’s; a holding is a source’s. Each source that holds an album has a holding of it, found again on every collection by the key the source knows it by, so the album keeps its ID. A collection replaces its source’s holdings; an album no holding refers to is removed, and then an artist with no albums.

Incident Record Template (INC)

Mon, 01 Jan 0001 00:00:00 +0000

Incident Record Template (INC)

The shape every incident record takes. Copy the skeleton into docs/content/docs/incidents/<YYYY>/<NNNN>-<slug>.md, numbered with the next unused INC-NNNN, and add a row to the index.

Start the record while the incident is fresh, even with most sections empty. The timeline and the wrong turns are the parts memory loses first.

Status

An incident carries a status and a substatus. The status says whether anything is left to do; the substatus says how far along it is, and only moves forward.

Where It Runs

Mon, 01 Jan 0001 00:00:00 +0000

Where It Runs

eds-inventory runs in EdS’s Deevnet IoTaaS tenant, beside EdS’s own services. It is its own project, in its own repository, with its own releases; it shares a tenant with its first client, not a codebase.

Why the same tenant

A tenant has no way in. Deevnet IoTaaS’s tenant fabric has no inbound path by design (Deevnet ADR-0001, Deevnet ADR-0003); it is why EdS’s broker lives outside EdS’s tenant. A service in another tenant could not be asked over HTTP by EdS’s services without a path Deevnet IoTaaS does not offer. In the same tenant, EdS asks the inventory as lightd asks palette: one service to another, on the same network.
Nothing is invented for it. No new path between tenants, and no Deevnet IoTaaS decision to wait on.

Sharing a tenant does not change the boundary. The inventory still knows nothing about EdS, and is still reached only through its contract.

ADR-0003: It Deploys Itself to EdS's Workload

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0003: eds-inventory Deploys Itself onto EdS’s Services Workload, from Its Own Repository


Status	Accepted 2026-10-24
Date	2026-10-24
Scope	How inventoryd reaches the machine it runs on, and how a library reaches it. Not which machine that is in the long run: EdS’s back end may become several Pis, and which services go where is open.
Extends	Where It Runs: EdS’s tenant, since a tenant has no way in from another

Context

The inventory runs in EdS’s Deevnet IoTaaS tenant, and its first client, EdS’s voiced, runs on EdS’s services workload. EdS deploys its own services there from its repository (make -C deploy), as container images under systemd, built on the Builder and sent at a capped rate after its deploys hung the core router (EdS INC-0002).

Proposed Schema

Mon, 01 Jan 0001 00:00:00 +0000

Proposed Schema

Not built. This is the database as it is being reworked, table by table, in conversation with the owner (started 2026-10-24). What is agreed is in color; what is still to review, or proposed but not agreed, is gray. When the review is done, the schema is rebuilt as one clean version 1, the workload’s database is wiped, and the library collected again. Until then, Database Schema is what runs.