Motivation
A repo's configured blob stores currently live in the mutable config's blob-stores TOML array (repo_configs.V2.BlobStores), editable only by hand-editing via edit-config. der info-repo can only inspect the default store's config keys — there's no first-class way to list what stores a repo knows about, add one, or remove one.
Surfaced during a der reindex investigation where a repo's blob-store resolution had drifted (a store's blobs became unreachable after the ambient XDG_DATA_HOME changed) and there was no dedicated tooling to inspect or fix the blob-stores list short of hand-editing TOML.
Ask
Design and implement:
der blob_store-list — show the repo's configured blob-stores order, which one is default, and (ideally, sharing logic with the proposed der health-blob_store, tracked separately) whether each currently resolves/is reachable.der blob_store-add — register a store (by id, with prefix/location) into the repo's blob-stores order.der blob_store-remove — deregister one.
Should be built on whatever paved-path blob-store accessors come out of the GetDefaultBlobStore() audit (#352), not add another ad hoc resolution path. Needs to decide: does add/remove only touch the ordered id list (madder owns the actual store's existence/config), or can it also provision a new store (i.e. wrap madder init)?
:clown: Filed by Clown 0.3.19+f1e3833 (build).
Motivation
A repo's configured blob stores currently live in the mutable config's
blob-storesTOML array (repo_configs.V2.BlobStores), editable only by hand-editing viaedit-config.der info-repocan only inspect the default store's config keys — there's no first-class way to list what stores a repo knows about, add one, or remove one.Surfaced during a
der reindexinvestigation where a repo's blob-store resolution had drifted (a store's blobs became unreachable after the ambient XDG_DATA_HOME changed) and there was no dedicated tooling to inspect or fix theblob-storeslist short of hand-editing TOML.Ask
Design and implement:
der blob_store-list— show the repo's configuredblob-storesorder, which one is default, and (ideally, sharing logic with the proposedder health-blob_store, tracked separately) whether each currently resolves/is reachable.der blob_store-add— register a store (by id, with prefix/location) into the repo'sblob-storesorder.der blob_store-remove— deregister one.Should be built on whatever paved-path blob-store accessors come out of the
GetDefaultBlobStore()audit (#352), not add another ad hoc resolution path. Needs to decide: doesadd/removeonly touch the ordered id list (madder owns the actual store's existence/config), or can it also provision a new store (i.e. wrapmadder init)?:clown: Filed by Clown 0.3.19+f1e3833 (build).