VictoriaMetrics / VictoriaMetrics/operator

Feature request: Automatic PVC storage size increase

Open
#1,310 5 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
589
Forks
229
Avg merge
1d 9h
Merged PRs (30d)
77

Description

It would be really cool if the operator could automatically increase the size of PVCs for VMSingle and VMCluster.

This was mentioned way back in an issue here: https://github.com/VictoriaMetrics/operator/issues/161

Lets say we want to retain metrics "forever" (10 years?). If we can automatically "step up" the storage size instead of pre-allocating the expected storage size that would be about a 50% cost reduction.

Another benefit is the peace of mind that if we either miscalculate the storage requirements up front, the data volume increases or we forget to increase regularly it will just manage itself.

I imagine a spec that looks something like:

initialSize: 50G
storageResizeStep: 10G
maxStorageSize: 1000G

Threshold for doing the resize can be once there is less than storageResizeStep space available, to keep things simple.

maxStorageSize exists as a safety mechanism to avoid extreme surprises.

Additionally there should be metrics for storage_size_max and storage_size_current that allows for creating an alert to manually intervene if we're about to reach the maximum size and the automation would no longer help us.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the related issue #161 and tracing how the operator reconciles PVCs for VMSingle and VMCluster. Define the configuration and safety behavior for incremental expansion, maximum size handling, and the requested storage metrics, then verify the design against Kubernetes PVC expansion constraints and relevant reconciliation tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.