canonical / canonical/canonical-openstack-docs

docs: document per-service persistent storage sizing in enterprise requirements

Open Beginner friendly
#241 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.