Object Repository Contract¶
Defines the reusable cloud object storage contract consumed by backup/artifact modules.
Purpose¶
Keep storage provisioning separate from workload operations while avoiding provider-specific sprawl in downstream modules.
Pattern¶
- Provision repository infra via provider module:
org/aws/object-repoorg/gcp/object-repoorg/azure/object-repo
For GCP, prefer project_state_ref to consume project_id from upstream HyOps project state
(typically org/gcp/project-factory) when the project is managed in the same env.
Use explicit project_id only for external/pre-existing projects outside HyOps state.
Bucket names remain operator-specified and fail-fast validated; HyOps should not auto-generate them implicitly.
-
Consume repository via
repo_state_refin workload modules (e.g. PostgreSQL HA backup). -
Store credentials out-of-band (never mint secrets inside Terraform state).
Normalized output contract¶
All object-repo modules publish:
repo_backendrepo_providerrepo_bucket_namerepo_regionrepo_principal_typerepo_principal_namerepo_credential_create_hint
These outputs are provider-neutral and should be the only contract consumed by downstream modules/blueprints.
Module layering¶
- Generic foundation:
org/<provider>/object-repo- Workload-specific wrappers (optional):
org/<provider>/pgbackrest-repo
Wrappers may keep workload defaults (naming, principal IDs), but should preserve the same normalized outputs.
DRY rules¶
- Avoid duplicating Terraform logic across generic and wrapper modules.
- Reuse the same Terragrunt/Terraform pack where possible.
- Keep provider-specific details at the infra module boundary.
- Keep operation modules consuming
repo_state_refinstead of duplicating bucket/container values.
Security rules¶
- Do not create long-lived access secrets in Terraform state.
- Generate credentials out-of-band (CLI/identity workflow).
- Store runtime secrets in HyOps vault and reference by env key.
Backend/runtime compatibility¶
- Provisioning path is
hyops -> terragrunt -> terraform. - Backend mode (
localorcloud) is controlled by profile/root templates. - Credential tfvars requirements are enforced by profile credential contracts.