canonical / canonical/canonical-openstack-docs
docs: document per-service persistent storage sizing in enterprise requirements
- Dominant language
- Python
- Stars
- 10
- Forks
- 36
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 5
Description
The "Enterprise Requirements" page currently lists minimum hardware specifications (CPU, RAM, root disk, network) but does not document how persistent volume sizes are assigned per service in the deployment manifest.
## Proposed changes
The following changes should be applied:
- Add a short section or note stating that persistent storage is configured per service under the manifest storage section, e.g.
`mysql-k8s storage.database` and `opentelemetry-collector-k8s storage.persisted`.
- Clarify that sizes should be planned according to each workload's growth before production rollout, because online volume expansion is not supported on the default local OpenEBS storage class (`allowVolumeExpansion=false`).
Suggested starting values, based on experience from a deployment with this stack:
| Component | Manifest key | Suggested size |
|---|---|---|
| MySQL (K8s) | `mysql-k8s storage.database` | 350 GiB |
| OpenTelemetry Collector (K8s) | `opentelemetry-collector-k8s storage.persisted` | 50 GiB |
_**Note:** These are field experience starting points, not an official specification; every deployment should validate sizing against the actual workload growth before rollout._
## Rationale
- Operators reading the current page may assume default values apply both for Testing/Development and Production environments.
- Deployers need a documented reference for where and how to set these sizes.
---
*Reported from: https://canonical-openstack.readthedocs-hosted.com/en/latest/reference/enterprise-requirements/*
Contributor guide
Research direction
Start at the Enterprise Requirements page linked in the issue and inspect the deployment manifest's storage section and the default local OpenEBS storage class. Document the per-service keys, suggested starting values, workload-growth planning, and lack of online expansion; done means the page clearly distinguishes these recommendations from official specifications.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, mysql
- Domain
- documentation, infrastructure
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100