38 lines
1.4 KiB
Markdown
38 lines
1.4 KiB
Markdown
# Dormant Implementation Report
|
|
|
|
## Classification
|
|
|
|
### Runtime
|
|
|
|
- `manifest/base/runtime/deployment.yaml`
|
|
- `manifest/base/runtime/service.yaml`
|
|
- `manifest/overlays/production/ingressroute.yaml`
|
|
- `manifest/overlays/production/secret-generator.yaml`
|
|
- `manifest/overlays/production/secret.secret.yaml`
|
|
|
|
These resources are only required while the app is running.
|
|
|
|
### Retained state
|
|
|
|
- `manifest/base/state/persistentvolumeclaim.yaml`
|
|
- optional `manifest/overlays/production/storage/persistentvolume-nfs.yaml` example
|
|
|
|
The PVC must survive dormancy so the app can restart with the same data later.
|
|
|
|
### Components kept in place
|
|
|
|
- `manifest/components/example-component/*`
|
|
|
|
This remains in `components` because it is shared template material, not app-owned runtime or retained state.
|
|
|
|
## Ambiguities and safe choices
|
|
|
|
- The namespace is not declared in-repo, so there is nothing here to prune. Namespace lifecycle remains outside this manifest set.
|
|
- Dynamic PV reclaim behavior is controlled by the cluster storage class or Longhorn settings, not this repo. That prerequisite is documented in `OPERATIONS.md`.
|
|
|
|
## Validation checklist
|
|
|
|
- Production active render before/after should stay materially equivalent for `Deployment`, `Service`, `IngressRoute`, `Secret`, and `PersistentVolumeClaim`.
|
|
- Dormant render should retain only the PVC.
|
|
- No component resources were moved or pruned by this refactor.
|