Commit d5fc723

"description": "Optional disk-usage cap as a VictoriaMetrics BytesString (e.g. \"8GB\" or \"8GiB\"), bounding disk use on top of the age-based retentionPeriod. Uses byte-suffix grammar (kb/mb/gb/tb, KiB/MiB/GiB/TiB), NOT the Kubernetes-quantity grammar of the sibling storage field, so \"8Gi\" is rejected by the operator. In cluster mode the cap is per vtstorage replica (replicaCount 2), so the effective total is twice the value. Unset, the store drops its oldest day once its filesystem is 80% full instead, so every store is disk-bounded. Either way VictoriaTraces keeps the last two days, so spans arriving faster than the cap allows for two days can still fill the disk.",

"description": "tenant-root only: accept spans from tenants that turned on shared-central tracing (the Tenant's tracingCentral) into this Monitoring's tracingStorages entry named `generic`, which must be in `cluster` mode. Every central tenant then shares that store's disk and retention with tenant-root, and nothing reserves space or limits the rate per tenant: once the store's disk cap is reached (retentionDiskUsageBytes, or 80% of its filesystem) the oldest spans of all of them are evicted together, and a tenant sending faster than the cap allows for the two days VictoriaTraces always keeps can fill the disk for all of them. Ignored outside tenant-root. The tenant-root namespace is inside the trust boundary of the shared store, as it is for the metrics of tenants that rely on a parent's monitoring: vmauth pins each central tenant to its own account, but workloads in tenant-root reach the store directly, and one that learns a tenant's account ID (a hash of its namespace name and UID, which its VMUser carries) can read and write that account. Whoever tenant-root admits to its Grafana is inside it too, since tenant-root's own datasource for the store reaches vtselect without vmauth; who that is follows its Grafana's oidc mode (with System, tenant-root's own groups, which already hold the same access level in every tenant under tenant-root). The render refuses to stop hosting while central tenants remain, but removing the tenant-root Monitoring altogether is not a render and is not refused: turn tracingCentral off on the central tenants first, since until then every Monitoring render of theirs fails, their metrics, logs and alerting changes included. The refusals read each other's objects when they render, so a tenant turning tracingCentral on while tenant-root stops hosting can pass both: that tenant's collector then exports to a vmauth that is gone while every release reports Ready, until its Monitoring renders again. Recover by hosting again; turning that tenant's tracingCentral off instead ends the silent drop, and turning it on again is then refused until tenant-root hosts.",

## @param {bool} tracingCentralHost - tenant-root only: accept spans from tenants that turned on shared-central tracing (the Tenant's tracingCentral) into this Monitoring's tracingStorages entry named `generic`, which must be in `cluster` mode. Every central tenant then shares that store's disk and retention with tenant-root, and nothing reserves space or limits the rate per tenant: once the store's disk cap is reached (retentionDiskUsageBytes, or 80% of its filesystem) the oldest spans of all of them are evicted together, and a tenant sending faster than the cap allows for the two days VictoriaTraces always keeps can fill the disk for all of them. Ignored outside tenant-root. The tenant-root namespace is inside the trust boundary of the shared store, as it is for the metrics of tenants that rely on a parent's monitoring: vmauth pins each central tenant to its own account, but workloads in tenant-root reach the store directly, and one that learns a tenant's account ID (a hash of its namespace name and UID, which its VMUser carries) can read and write that account. Whoever tenant-root admits to its Grafana is inside it too, since tenant-root's own datasource for the store reaches vtselect without vmauth; who that is follows its Grafana's oidc mode (with System, tenant-root's own groups, which already hold the same access level in every tenant under tenant-root). The render refuses to stop hosting while central tenants remain, but removing the tenant-root Monitoring altogether is not a render and is not refused: turn tracingCentral off on the central tenants first, since until then every Monitoring render of theirs fails, their metrics, logs and alerting changes included. The refusals read each other's objects when they render, so a tenant turning tracingCentral on while tenant-root stops hosting can pass both: that tenant's collector then exports to a vmauth that is gone while every release reports Ready, until its Monitoring renders again. Recover by hosting again; turning that tenant's tracingCentral off instead ends the silent drop, and turning it on again is then refused until tenant-root hosts.

Every store is disk-bounded, not only age-bounded, so a full PVC cannot

block ingest: without a byte cap it drops its oldest day once its filesystem

is 80% full. VictoriaTraces refuses to start with both limits, so only one is

rendered. It always keeps the last two days, which a flood faster than that

can still push past the limit.

{{- else }}

extraArgs:

retention.maxDiskUsagePercent: "80"

{{- else }}

extraArgs:

retention.maxDiskUsagePercent: "80"

# The design requires every traces backend to be disk-bounded, not only

# age-bounded, so a full PVC cannot block ingest. Without an explicit byte cap

# the store drops its oldest day once its filesystem is 80% full. The two

# flags are mutually exclusive: VictoriaTraces refuses to start with both.

- it: bounds a cluster-mode store at 80% of its filesystem without a byte cap

templates:

- templates/vtraces/vtraces.yaml

set:

tracingStorages:

- name: generic

mode: cluster

retentionPeriod: "14d"

storage: 10Gi

asserts:

- equal:

path: spec.storage.extraArgs["retention.maxDiskUsagePercent"]

value: "80"

- notExists:

path: spec.storage.retentionMaxDiskSpaceUsageBytes

- it: bounds a single-mode store at 80% of its filesystem without a byte cap

templates:

- templates/vtraces/vtraces.yaml

set:

tracingStorages:

- name: generic

mode: single

retentionPeriod: "14d"

storage: 10Gi

asserts:

- equal:

path: spec.extraArgs["retention.maxDiskUsagePercent"]

value: "80"

- notExists:

path: spec.retentionMaxDiskSpaceUsageBytes

- it: sets no percentage cap on a cluster-mode store that has a byte cap

templates:

- templates/vtraces/vtraces.yaml

set:

tracingStorages:

- name: generic

mode: cluster

retentionPeriod: "14d"

storage: 10Gi

retentionDiskUsageBytes: "8GB"

asserts:

- notExists:

path: spec.storage.extraArgs

- it: sets no percentage cap on a single-mode store that has a byte cap

templates:

- templates/vtraces/vtraces.yaml

set:

tracingStorages:

- name: generic

mode: single

retentionPeriod: "14d"

storage: 10Gi

retentionDiskUsageBytes: "4GB"

asserts:

- notExists:

path: spec.extraArgs