Merge pull request 'Issue 263: every consumer pays for the tightest backend's name limit' (#118) from issues/263-the-identity-limit into main
This commit was merged in pull request #118.
This commit is contained in:
@@ -0,0 +1,61 @@
|
||||
---
|
||||
status: open
|
||||
opened: 2026-10-06
|
||||
located-in: []
|
||||
fixed-by:
|
||||
amended-design:
|
||||
---
|
||||
|
||||
# 263. Every consumer pays for the tightest backend's name limit
|
||||
|
||||
## Symptom
|
||||
|
||||
The operator: "the 20 character limit has bitten us multiple times". Most recently, on 2026-10-06:
|
||||
|
||||
- A change made the network-manager modules require the mesh's resolver provision.
|
||||
- Each machine running them thereby became a consumer of that provision, with an identity
|
||||
`mesh_<machine>_<module>`.
|
||||
- `networkmanager`'s identity is 23 to 26 characters, over the 20 the controller allows.
|
||||
|
||||
The refusal surfaced as the anchor's whole declaration failing to compose, because the anchor carries
|
||||
every consumer's grant as the resolver's holder:
|
||||
|
||||
> networkmanager on <home-server> is identified as "mesh_<home-server>_networkmanager", 23 characters
|
||||
> where a backend (an S3 access key) keeps 20 — give the module a shorter `slug` or shorten the
|
||||
> machine's name
|
||||
|
||||
For as long as that lasted, no push to the anchor could go through. The fix was another slug.
|
||||
|
||||
## Why it keeps happening
|
||||
|
||||
[ADR 0049](../../02-DECISIONS/0049-a-consumers-identity-fits-the-tightest-backend.md) bounds **every**
|
||||
consumer's identity by the tightest backend anywhere, an object store's 20-character access key
|
||||
([issue 034](../034-mesh-login-exceeds-s3-access-key-limit/00-report.md)), and makes a module `slug`
|
||||
the remedy. That has two costs:
|
||||
|
||||
- **The limit applies where it means nothing.** The resolver provision mints no credential and keeps
|
||||
no name in any backend, yet its consumers were held to an object store's key length. ADR 0049 named
|
||||
per-provision bounds (its option C) as the refinement for later. It has not been done.
|
||||
- **It is found late, and far from its cause.** The catalogue's module check and the controller's
|
||||
tests passed. The refusal came only when a real machine's name met the module's name, and it showed
|
||||
on the provider's machine, not on the consumer's, as a whole node that could not be pushed. ADR
|
||||
0049 says it is refused at assignment. This one was a new requirement on modules already assigned,
|
||||
so assignment never saw it.
|
||||
|
||||
## What to look into
|
||||
|
||||
1. **Bound each provision by its own backend's limit**, ADR 0049's option C. Only a provision that
|
||||
creates a name in a limited backend carries the limit, and a keyless one carries none.
|
||||
2. **Refuse it before merge.** The catalogue check should judge a module's identity against the
|
||||
longest machine name in the mesh (or the bound per provision) for every provision it requires, so
|
||||
the refusal names the module in its own pull request.
|
||||
3. **Never refuse a provider's whole declaration** for one consumer's identity. Leave that consumer's
|
||||
grant out, say so in `status`, and keep the provider's machine pushable.
|
||||
|
||||
## How it is checked (once fixed)
|
||||
|
||||
- A catalogue test: a module requiring a keyless provision composes with a long name.
|
||||
- A module check: a module requiring a limited provision is refused when the longest machine's
|
||||
identity overflows.
|
||||
- A controller test: an overflowing consumer leaves the provider's declaration composable, and is
|
||||
reported.
|
||||
Reference in New Issue
Block a user