jschoubben
22a28ad548
Issue 123 resolved; glossary corrected; design 26 and ADR 0121 point at the rename.
84 lines
4.9 KiB
Markdown
84 lines
4.9 KiB
Markdown
---
|
|
topic: the mesh
|
|
status: accepted
|
|
date: 2026-09-30
|
|
deciders: jochen
|
|
reconstructed: false
|
|
extends: 02-DECISIONS/0075-two-stores-and-which-provides-what.md
|
|
---
|
|
|
|
# 156. An artifact is what a build produces, the artifact store serves every kind, and its seat is named for its scope
|
|
|
|
## Context
|
|
|
|
[Issue 123](../04-ISSUES/123-the-image-registry-is-named-after-a-role/00-report.md) found three
|
|
wordings disagreeing about the mesh's registry. The glossary defined *artifact* as "an OCI image, by
|
|
digest"; the manifest's build vocabulary names four kinds — `image`, `upstream`, `bundle`, `archive` —
|
|
and the catalogue builds all four; the seat was `the-artifact-store`, the last of the mesh's own seats
|
|
named after the job it does rather than for the mesh
|
|
([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md) decided the
|
|
rename and deferred it). The issue asked whether the seat and provision should be renamed after
|
|
images, and whether the mesh needs two registry implementations at all.
|
|
|
|
Reading what the store actually serves settles the first question the other way. A kept reference
|
|
has two shapes — `artifact-store://<module>/<artifact>@sha256:…` for an image and
|
|
`artifact-store://<module>/<artifact>/blobs/sha256:…` for an archive — and both are served by the
|
|
same OCI registry, by digest. [ADR 0075](0075-two-stores-and-which-provides-what.md) already
|
|
defined the provision that way: *content-addressed blobs, pinned by digest, no versions, no ranges;
|
|
what the mesh delivers to machines*. The provision was never an image registry. Only the glossary said
|
|
so, and only the seat's name was odd.
|
|
|
|
## Considered Options
|
|
|
|
**1. Rename the seat and the provision after images.** Rejected. The store serves archives too, by the
|
|
same protocol; naming it for one kind would be the glossary's mistake made permanent, in the name
|
|
every manifest uses.
|
|
|
|
**2. Fix the word, rename the seat for its scope, keep the provision.** Chosen. The rename ADR 0121
|
|
deferred as a delivering-seat migration is, since [ADR 0122](0122-a-seat-is-data-a-rename-is-a-database-update.md),
|
|
one update and one alias: the former name resolves forever, a held record follows by cascade, a claim
|
|
written with the old name still holds.
|
|
|
|
**On two implementations:** left as 0075 decided. Two provisions because two protocols; the OCI
|
|
registry the genesis installs because something must serve images before the mesh can build; the
|
|
forge may provide `artifact-store` too and a mesh may choose it. The bootstrap argument is weaker than
|
|
it reads, as 123 says, and the day the forge is raised at genesis and adopted in place is the day to
|
|
retire the second server — a migration a mesh performs, not a decision to take here.
|
|
|
|
## Decision
|
|
|
|
- **An artifact is anything a build produces** — an image, a mirrored upstream image, a bundle, an
|
|
archive — and the glossary says so. *Image* is one kind. A module is not an image; a module may
|
|
build several artifacts and install none.
|
|
- **The artifact store serves artifacts of every kind a machine fetches**, images and archives, by
|
|
digest, over the OCI registry protocol. The provision keeps its name.
|
|
- **The seat is `mesh-artifact-store`.** `the-artifact-store` is its alias. The catalogue's registry
|
|
module claims the new name; a definition elsewhere claiming the old one still holds.
|
|
- The two other deferred renames — `npm-package-registry` and `git` — stay deferred, and for the
|
|
same reason no longer. They are one migration each when wanted; nothing here needs them.
|
|
|
|
## Consequences
|
|
|
|
- The glossary stops contradicting the manifest vocabulary, and a reader of `artifact-store` reads
|
|
it as what it is: where the mesh's built things are kept.
|
|
- One migration on the seat table; no manifest but the registry's changes; no consumer of the
|
|
provision changes, because the provision did not.
|
|
- **What got harder:** nothing measurable. A record that says `the-artifact-store` is read through the
|
|
alias; design 26's table already carried the new name as intent.
|
|
|
|
## How this is checked
|
|
|
|
| Rule | Checked by |
|
|
|---|---|
|
|
| The former name resolves to the seat once the store's aliases are loaded | a catalogue test |
|
|
| The seat is in the compiled set under its new name, delivering `artifact-store` | the seat tests, updated |
|
|
| The registry module holds the seat under the new name on the live mesh | `seats` after the rollout |
|
|
| The glossary's *artifact* matches the build kinds a manifest may declare | design 18's table and the showcase module list the kinds; the glossary names the same four |
|
|
|
|
## References
|
|
|
|
- [issue 123](../04-ISSUES/123-the-image-registry-is-named-after-a-role/00-report.md)
|
|
- [ADR 0075](0075-two-stores-and-which-provides-what.md) — extended: the provision as defined stands, the word is corrected
|
|
- [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md), [ADR 0122](0122-a-seat-is-data-a-rename-is-a-database-update.md) — the rename, decided and made cheap
|
|
- mesh-controller migration 0048; mesh-catalog `modules/distribution`
|