Retire completed one-time service import and bootstrap scaffolding #228

Closed
opened 2026-09-13 06:58:49 +01:00 by nimmo · 1 comment
Owner

Context

The native Vega Karakeep migration left one-time import wiring in the live configuration even though the import is intended only for first startup. This cleanup is a follow-up to #185, not authorisation to remove source data or perform a public ingress cutover.

Confirmed repository remnants

  • hosts/vega/default.nix still sets nixosConfig.karakeep.importSource = /mnt/storage/karakeep-import-complete.
  • modules/services/karakeep.nix still defines the importSource option, conditional karakeep-state-import one-shot, and karakeep-init ordering. The guarded import only copies into an empty target, but remains in the evaluated service graph while the host option is set.
  • modules/services/trilium-web.nix retains an optional first-run syncBootstrapPasswordSopsKey and trilium-sync-bootstrap unit. Vega does not configure the bootstrap inputs, so this unit is dormant, not an active import. hosts/vega/default.nix nevertheless lists trilium-sync-bootstrap unconditionally in the failure monitor. Review and retire the one-time path if no supported future consumer remains.
  • README.md still describes media1 as the live Karakeep service and the import as pending; secrets/README.md still documents the first-start import. Reconcile those claims with actual ingress and service state before rewriting them.

Safety boundaries

  • First verify the real Karakeep import result, current public ingress owner, Vega application health, a usable backup/read-back, and the rollback window. Do not infer those from the Nix declaration or the closed migration issue.
  • Do not delete or prune /mnt/storage/karakeep-import-complete, media1 Docker volumes, images, stack files, or other user data in this cleanup. Preserve the existing rollback copy unless separately authorised.
  • Do not alter SOPS values, live routing, or another service migration as part of removing dead code. If the import or cutover is still needed, keep this issue open until its prerequisites are met.

Work

  1. Confirm live ownership and recovery evidence in this issue.
  2. Remove the Karakeep importSource host setting and, when no consumer remains, its module option, one-shot import unit, and init ordering while retaining the native state and backup declaration.
  3. Remove the stale unconditional Trilium bootstrap failure-monitor entry. Check whether any host uses the optional Trilium bootstrap feature; if none and no supported use is retained, remove its one-time unit/options/secret wiring. If a future bootstrap is deliberately required, document that decision separately rather than silently keeping migration scaffolding.
  4. Correct README.md, secrets/README.md, and affected wiki references to the verified current state.

Acceptance

  • Nix validation and relevant service tests pass; Vega Karakeep and Trilium still work through their real client routes.
  • A Vega canary and no-op follow-up are recorded before closing this service-impacting issue.
  • The removed import/bootstrap units are absent from the evaluated host configuration, and no authoritative or rollback data was deleted.
  • Backup coverage and recovery route remain verified; no stale one-time import instructions remain.
## Context The native Vega Karakeep migration left one-time import wiring in the live configuration even though the import is intended only for first startup. This cleanup is a follow-up to #185, not authorisation to remove source data or perform a public ingress cutover. ## Confirmed repository remnants - hosts/vega/default.nix still sets nixosConfig.karakeep.importSource = /mnt/storage/karakeep-import-complete. - modules/services/karakeep.nix still defines the importSource option, conditional karakeep-state-import one-shot, and karakeep-init ordering. The guarded import only copies into an empty target, but remains in the evaluated service graph while the host option is set. - modules/services/trilium-web.nix retains an optional first-run syncBootstrapPasswordSopsKey and trilium-sync-bootstrap unit. Vega does not configure the bootstrap inputs, so this unit is dormant, not an active import. hosts/vega/default.nix nevertheless lists trilium-sync-bootstrap unconditionally in the failure monitor. Review and retire the one-time path if no supported future consumer remains. - README.md still describes media1 as the live Karakeep service and the import as pending; secrets/README.md still documents the first-start import. Reconcile those claims with actual ingress and service state before rewriting them. ## Safety boundaries - First verify the real Karakeep import result, current public ingress owner, Vega application health, a usable backup/read-back, and the rollback window. Do not infer those from the Nix declaration or the closed migration issue. - Do not delete or prune /mnt/storage/karakeep-import-complete, media1 Docker volumes, images, stack files, or other user data in this cleanup. Preserve the existing rollback copy unless separately authorised. - Do not alter SOPS values, live routing, or another service migration as part of removing dead code. If the import or cutover is still needed, keep this issue open until its prerequisites are met. ## Work 1. Confirm live ownership and recovery evidence in this issue. 2. Remove the Karakeep importSource host setting and, when no consumer remains, its module option, one-shot import unit, and init ordering while retaining the native state and backup declaration. 3. Remove the stale unconditional Trilium bootstrap failure-monitor entry. Check whether any host uses the optional Trilium bootstrap feature; if none and no supported use is retained, remove its one-time unit/options/secret wiring. If a future bootstrap is deliberately required, document that decision separately rather than silently keeping migration scaffolding. 4. Correct README.md, secrets/README.md, and affected wiki references to the verified current state. ## Acceptance - Nix validation and relevant service tests pass; Vega Karakeep and Trilium still work through their real client routes. - A Vega canary and no-op follow-up are recorded before closing this service-impacting issue. - The removed import/bootstrap units are absent from the evaluated host configuration, and no authoritative or rollback data was deleted. - Backup coverage and recovery route remain verified; no stale one-time import instructions remain.
Author
Owner

Implemented and validated on main.

  • Commit 3dce6f8 removed the Karakeep import scaffolding and Trilium bootstrap wiring.
  • nix flake check --no-build passed; evaluated Vega configuration confirms karakeep-state-import and trilium-sync-bootstrap are absent.
  • Vega is running downstream main revision 4e73708 (auto-update commit from 2026-09-15), with the cleanup commit in its ancestry.
  • Live canary/no-op evidence: Karakeep, Trilium, and Backrest are active; https://links.nimmog.uk returned 307 and https://notes.nimmog.uk returned 200.
  • Backrest recorded scheduled backup and snapshot-index tasks through 2026-09-15. The native Karakeep state and preserved /mnt/storage/karakeep-import-complete rollback snapshot remain intact; no data or SOPS values were deleted.
Implemented and validated on main. - Commit `3dce6f8` removed the Karakeep import scaffolding and Trilium bootstrap wiring. - `nix flake check --no-build` passed; evaluated Vega configuration confirms `karakeep-state-import` and `trilium-sync-bootstrap` are absent. - Vega is running downstream main revision `4e73708` (auto-update commit from 2026-09-15), with the cleanup commit in its ancestry. - Live canary/no-op evidence: Karakeep, Trilium, and Backrest are active; `https://links.nimmog.uk` returned 307 and `https://notes.nimmog.uk` returned 200. - Backrest recorded scheduled backup and snapshot-index tasks through 2026-09-15. The native Karakeep state and preserved `/mnt/storage/karakeep-import-complete` rollback snapshot remain intact; no data or SOPS values were deleted.
nimmo closed this issue 2026-09-15 06:53:14 +01:00
Sign in to join this conversation.
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
nimmo/nixos-config#228
No description provided.