VictoriaMetrics / VictoriaMetrics/operator
VMAnomaly CR requires content in configRawYaml even with VMAnomalyConfig CR
@AndrewChubatiuk is already working on this.
Since Aug 22, 2026.
- Dominant language
- Go
- Stars
- 589
- Forks
- 229
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 77
Description
If a user wishes to store queries, models, and schedulers in VMAnomalyConfigCR they must put some configuration in configRawYaml in order for operator to not reject the CR.
as an example
configRawYaml: | # these are a placeholder that operator 0.73.1 expects. reader: queries: dummy: expr: 'dummy' step: '1m' schedulers: dummy_periodic: class: "periodic" infer_every: "1d" fit_every: "1d" fit_window: "1m" models: dummY_zscore: class: zscore z_threshold: 3.0 queries: ['dummy'] schedulers: ['dummy_periodic']
even with a configCR defined like this.
apiVersion: operator.victoriametrics.com/v1 kind: VMAnomalyConfig metadata: name: anomaly-config namespace: victoriametrics-obs labels: tenant: "1" spec: schedulers: scheduler_periodic_1m: class: periodic infer_every: "1m" fit_every: "1h" fit_window: "168h" models: zscore: class: zscore_online z_threshold: 3.0 queries: ['test1'] schedulers: ['scheduler_periodic_1m'] queries: test1: expr: 'test_1' step: "1m"
One approach would be to drop the requirement and validation for configRawYaml as using VMAnomaly for only experiments and investigation is a use case as in no config use only vmuii.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.