feat(monitoring): migrate VictoriaLogs from VLogs to VLCluster - #2153

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/README.md (1)

3-3: Use descriptive link text on Line 3.

[here] trips MD059 and is less accessible in rendered docs. Make the link text describe the destination.

📝 Proposed fix

-Chart documentation is available [here](https://docs.victoriametrics.com/helm/victoria-metrics-common/)
+Chart documentation is available in the [VictoriaMetrics Common Helm chart documentation](https://docs.victoriametrics.com/helm/victoria-metrics-common/)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/README.md`
at line 3, Replace the vague link text "[here]" in README.md with a descriptive
phrase (e.g., "VictoriaMetrics Common Helm chart documentation" or
"VictoriaMetrics Common Helm chart docs") so the markdown link reads like
"[VictoriaMetrics Common Helm chart
documentation](https://docs.victoriametrics.com/helm/victoria-metrics-common/)";
just update the link text and keep the existing URL to satisfy
accessibility/MD059.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/RELEASE_NOTES (1)

7-7: Consider expanding release notes with breaking change context.

The operator version v0.68.1 is valid, but the release notes omit important context: VLogs was deprecated in v0.59.0 and became read-only starting v0.61.0. By v0.68.1, users who have not migrated to VLCluster or VLSingle will be running with a read-only VLogs, which is a breaking change affecting deployments and requiring manual migration. Add a note referencing the migration path or link to the operator's VLogs deprecation documentation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/RELEASE_NOTES`
at line 7, Update the RELEASE_NOTES entry for v0.68.1 to explicitly call out the
VLogs deprecation and breaking-change impact: mention that VLogs was deprecated
in v0.59.0 and became read-only in v0.61.0, that v0.68.1 will run with read-only
VLogs for users who haven't migrated, and add guidance referencing the supported
migration paths (VLCluster and VLSingle) plus a link to the operator's VLogs
deprecation/migration documentation so operators know they must perform manual
migration.

packages/system/monitoring/templates/vpa.yaml (1)

90-178: Consider extracting a shared VPA helper for the VM and VL blocks.**

This section copies the existing metricsStorages VPA template almost verbatim. A small partial that takes the component name, workload kind, and default limits would make future policy/default changes much less likely to drift between the VM* and VL* resources.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/monitoring/templates/vpa.yaml` around lines 90 - 178, The VPA
blocks for vlinsert, vlselect, and vlstorage duplicate the same structure and
the metricsStorages VPA template; extract a Helm partial (e.g., define
"vpa.component") that accepts parameters: component name/alias ({{ .name }}),
workload kind (Deployment/StatefulSet), containerName
(vlinsert/vlselect/vlstorage) and default min/max values, then replace each
repeated block in packages/system/monitoring/templates/vpa.yaml (the range over
.Values.logsStorages and the individual blocks creating vpa-vlinsert-{{ .name
}}, vpa-vlselect-{{ .name }}, vpa-vlstorage-{{ .name }}) with calls to the new
partial via include (or template) passing the appropriate defaults so future
policy/default changes live in one place.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/serviceaccount.yaml (2)

4-4: Unused $fullname variable.

The $fullname variable is defined but never used in this template. Consider removing it to reduce clutter.

Suggested fix

 {{- $ctx := dict "helm" . }}
-{{- $fullname := include "vm.plain.fullname" $ctx }}
 {{- $ns := include "vm.namespace" $ctx }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/serviceaccount.yaml`
at line 4, The template defines an unused variable $fullname via include
"vm.plain.fullname" $ctx; remove that declaration from the serviceaccount.yaml
template (the line setting $fullname) to eliminate dead code, and verify no
other references to $fullname remain in this template (keep include usage only
where the resulting value is actually referenced).

---

20-22: Potential mutation of shared values reference.

Using set on $extraLabels may mutate the original .Values.upgrade.serviceAccount.labels if it's passed by reference. This could cause unexpected side effects in subsequent template renders.

Suggested fix using deepCopy

-  {{- $extraLabels := $sa.labels | default dict }}
-  {{- $_ := set $extraLabels "app.kubernetes.io/component" "upgrade-crds" }}
+  {{- $extraLabels := deepCopy ($sa.labels | default dict) }}
+  {{- $_ := set $extraLabels "app.kubernetes.io/component" "upgrade-crds" }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/serviceaccount.yaml`
around lines 20 - 22, $extraLabels is assigned from $sa.labels and then mutated
via set, which can modify the original shared value; to fix, create a defensive
copy (use deepCopy) of $sa.labels before calling set so mutations don't affect
the original .Values, then assign the modified copy into $ctx (referencing
$extraLabels, $sa.labels, set and $ctx in the template).

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/values.yaml (1)

9-11: Consider pinning the busybox image tag instead of using latest.

Using latest tag creates non-deterministic deployments and can lead to unexpected behavior if the upstream image changes. Consider pinning to a specific version (e.g., 1.36 or 1.37) for reproducible builds.

Suggested fix

   busybox:
     image:
       repository: busybox
-      tag: latest
+      tag: "1.37"
       pullPolicy: IfNotPresent

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/values.yaml`
around lines 9 - 11, The values.yaml currently pins the init image with
repository "busybox" and tag "latest"; change the tag from "latest" to a
specific, tested version (e.g., "1.36.1" or "1.37.0") to ensure deterministic
deployments, update any references to this image in templates that use the
values (look for usage of values like .Values.initImage.repository and
.Values.initImage.tag or similar), and update chart/README or changelog to
record the chosen pinned version so consumers know which busybox version the
chart relies on.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/crb.yaml (1)

26-31: Unnecessary namespace field on cluster-scoped resource.

ClusterRoleBinding is a cluster-scoped resource; the namespace field in metadata is ignored by Kubernetes. While harmless, removing it improves clarity.

Suggested fix

 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: {{ $fullname }}-cleanup-hook
-  namespace: {{ $ns }}
   labels: {{ include "vm.labels" $ctx | nindent 4 }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/crb.yaml`
around lines 26 - 31, The ClusterRoleBinding template includes an unnecessary
metadata.namespace entry; remove the `namespace: {{ $ns }}` line from the
ClusterRoleBinding resource (the block that creates the {{ $fullname
}}-cleanup-hook ClusterRoleBinding) so the cluster-scoped resource has no
namespace field while leaving labels ({{ include "vm.labels" $ctx }}) and other
metadata intact.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/role.yaml (1)

163-169: Inconsistent indentation in RBAC rule.

This rule block uses extra indentation for apiGroups and resources compared to adjacent rules (e.g., lines 170-176). While functional, it reduces consistency.

🔧 Suggested fix for consistent formatting

 - apiGroups:
-    - gateway.networking.k8s.io
+  - gateway.networking.k8s.io
   resources:
-    - httproutes
-    - httproutes/finalizers
+  - httproutes
+  - httproutes/finalizers
   verbs:
-    - '*'
+  - "*"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/role.yaml`
around lines 163 - 169, The RBAC rule block for the Gateway API (the rule
listing apiGroups: gateway.networking.k8s.io and resources: httproutes,
httproutes/finalizers) has extra indentation compared to adjacent rules; update
the YAML so apiGroups, resources and verbs align at the same indentation level
as the other rule entries in the Role template (normalize spacing for the rule
containing httproutes to match the surrounding rules) to keep consistent
formatting.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/cleanup.yaml (1)

39-44: ⚠️ Potential issue | 🟡 Minor

Skip empty CRD documents when building the delete list.

If crd.yaml contains an empty document, this appends an empty resource name and can turn the kubectl delete argument into an invalid CSV list.

Possible fix

           {{- $names := list }}
           {{- $crds := .Files.Get "crd.yaml" | splitList "---" }}
           {{- range $crds }}
             {{- $crd := . | fromYaml }}
-            {{- $names = append $names $crd.spec.names.singular }}
+            {{- if and $crd $crd.spec $crd.spec.names $crd.spec.names.singular }}
+            {{- $names = append $names $crd.spec.names.singular }}
+            {{- end }}
           {{- end }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/cleanup.yaml`
around lines 39 - 44, When building the delete list from the splitList of
"crd.yaml" ($crds) skip empty/invalid documents before appending: inside the
range over $crds, after creating $crd := . | fromYaml, check that $crd is not
nil and that $crd.spec.names.singular exists and is non-empty before doing
$names = append $names $crd.spec.names.singular; this prevents appending empty
strings when the document is blank and avoids producing an invalid CSV for
kubectl delete.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/crd.yaml (1)

12-12: ⚠️ Potential issue | 🟠 Major

Restore metadata.labels on rendered CRDs.

$extra now injects only annotations, so the CRDs stop receiving vm.labels / .Values.global.extraLabels. That is a regression for clusters with required-label policies.

Possible fix

   {{- $crds := $files.Get "crd.yaml" | splitList "---" }}
   {{- $annotations := mergeOverwrite ((include "vm-operator.crds.annotations" .) | fromYaml) .Values.crds.annotations -}}
-  {{- $extra := dict "metadata" (dict "annotations" $annotations) -}}
+  {{- $_ := set $ctx "extraLabels" .Values.extraLabels -}}
+  {{- $labels := include "vm.labels" $ctx | fromYaml -}}
+  {{- $_ := unset $ctx "extraLabels" -}}
+  {{- $extra := dict "metadata" (dict "annotations" $annotations "labels" $labels) -}}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/crd.yaml`
at line 12, The rendered CRDs lost metadata.labels because $extra was rebuilt to
include only "annotations"; restore labels by adding a "labels" entry to the
$extra dict so CRDs receive vm.labels / .Values.global.extraLabels again (e.g.
change {{- $extra := dict "metadata" (dict "annotations" $annotations) -}} to
include "labels" referencing the existing $labels or vm.labels variable),
ensuring the dict keys are "metadata" -> (dict "annotations" $annotations
"labels" $labels).

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/role.yaml (1)

17-32: ⚠️ Potential issue | 🟠 Major

Split create away from the resourceNames restriction.

Kubernetes does not apply resourceNames to top-level create requests. Keeping create in this rule prevents the pre-install hook from creating missing CRDs on a fresh install.

🐛 Proposed fix

 rules:
   - apiGroups:
       - "apiextensions.k8s.io"
     resources:
       - "customresourcedefinitions"
     verbs:
       - create
+  - apiGroups:
+      - "apiextensions.k8s.io"
+    resources:
+      - "customresourcedefinitions"
+    verbs:
       - patch
       - update
       - get
       - list
     resourceNames:
       {{- range $crds }}
         {{- $crd := fromYaml . }}
       - {{ $crd.metadata.name }}
       {{- end }}

Kubernetes RBAC resourceNames create verb customresourcedefinitions

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/role.yaml`
around lines 17 - 32, The current Role rule lists the create verb alongside a
resourceNames-restricted rule for customresourcedefinitions, which prevents
cluster-level CRD creation; to fix, split the verbs into two rules: keep a rule
with apiGroups: ["apiextensions.k8s.io"] and resources:
["customresourcedefinitions"] containing only verbs that must be
resource-restricted (get, list, patch, update) and resourceNames: (the {{- range
$crds }} ... {{- end }} block), and add a separate rule for the same
apiGroups/resources that includes only the create verb (no resourceNames) so the
pre-install hook can create missing CRDs; locate this in the Role template where
rules, apiGroups, resources, verbs, and resourceNames are defined.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/serviceaccount.yaml (1)

18-27: ⚠️ Potential issue | 🟠 Major

Restore the crds.enabled guard on cleanup hooks.

This cleanup ServiceAccount now renders whenever crds.cleanup.enabled is true, even when the chart is not managing CRDs. That leaves the uninstall cleanup path able to touch CRDs the release never owned. Keep the cleanup hook behind both flags, and mirror the same combined guard in the matching cleanup RBAC/job templates.

🐛 Proposed fix

-{{- if .Values.crds.cleanup.enabled }}
+{{- if and .Values.crds.enabled .Values.crds.cleanup.enabled }}
 ---
 apiVersion: v1
 kind: ServiceAccount

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/serviceaccount.yaml`
around lines 18 - 27, The cleanup ServiceAccount is currently gated only by
.Values.crds.cleanup.enabled and should also require .Values.crds.enabled;
update the conditional in
templates/victoria-metrics-operator/templates/serviceaccount.yaml to require
both .Values.crds.enabled and .Values.crds.cleanup.enabled (so the block
creating the ServiceAccount named {{ $fullname }}-cleanup-hook with annotations
from "vm-operator.cleanup.annotations" only renders when both flags are true),
and apply the same combined guard to the corresponding cleanup RBAC and job
templates so cleanup hooks never run when CRD management is disabled.

packages/system/monitoring/templates/vlogs/vlogs.yaml (1)

13-31: Consider making replicaCount configurable via values.

The hardcoded replicaCount: 2 for all components is reasonable for production, but smaller environments or development clusters might benefit from configurable replicas.

🔧 Optional: Make replicaCount configurable

In values.yaml, add optional replica configuration:

logsStorages:
- name: generic
  retentionPeriod: "1"
  storage: 10Gi
  storageClassName: ""
  # Optional: defaults to 2 if not specified
  # replicaCount: 2

Then in the template:

   vlinsert:
-    replicaCount: 2
+    replicaCount: {{ .replicaCount | default 2 }}
     resources: {}
   vlselect:
-    replicaCount: 2
+    replicaCount: {{ .replicaCount | default 2 }}
     resources: {}
   vlstorage:
     retentionPeriod: {{ .retentionPeriod | quote }}
-    replicaCount: 2
+    replicaCount: {{ .replicaCount | default 2 }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/monitoring/templates/vlogs/vlogs.yaml` around lines 13 - 31,
The templates currently hardcode replicaCount: 2 for vlinsert, vlselect and
vlstorage; make this driven by the values file (e.g., per-storage entry
replicaCount) and fall back to 2 if unset. Update the vlinsert, vlselect and
vlstorage blocks to use the Helm value (such as
.Values.<yourValuesKey>.replicaCount or the per-storage entry’s .replicaCount)
with the Helm default function to supply 2 when not provided, and add the
optional replicaCount key to values.yaml so users can override replicas in
development or small clusters.

packages/system/monitoring/templates/vpa.yaml (1)

107-118: Expose the new logsStorages VPA knobs in the values surface.

This template now accepts .vlinsert/.vlselect/.vlstorage.{minAllowed,maxAllowed}, but packages/system/monitoring/values.yaml:43-47 only shows the basic logsStorages fields. The fallback logic is fine, but these overrides are effectively undocumented right now.

Also applies to: 136-147, 165-176

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/monitoring/templates/vpa.yaml` around lines 107 - 118, The
values surface is missing documented knobs for the VPA overrides used in the
template (.vlinsert, .vlselect, .vlstorage and their minAllowed/maxAllowed
entries), so update packages/system/monitoring/values.yaml to expose and
document these fields under logsStorages for each target (vlinsert, vlselect,
vlstorage) including nested minAllowed and maxAllowed blocks with the same
default CPU/memory values shown in the template (e.g., cpu: 25m / memory: 64Mi
for minAllowed and cpu: 2000m / memory: 4Gi for maxAllowed) so users can
override .vlinsert/.vlselect/.vlstorage.{minAllowed,maxAllowed}; apply the same
additions for the other occurrences mentioned (around the other template
regions).

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/README.md (1)

3-3: Use descriptive link text.

[here] is weak in rendered docs and for screen readers. Please link the chart/docs name instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/README.md`
at line 3, Replace the non-descriptive link text "[here]" in the README.md with
the chart/docs name so the link reads e.g. "victoria-metrics-common" (or
"Victoria Metrics Common chart documentation") and update the markdown link
target to the same URL
(https://docs.victoriametrics.com/helm/victoria-metrics-common/); locate the
line containing "Chart documentation is available [here](...)" in the README.md
and change the link label to the descriptive chart/docs name to improve
accessibility and clarity.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/.helmignore (1)

24-26: ⚠️ Potential issue | 🟠 Major

Avoid patching .helmignore inside the vendored chart.

This change directly edits a file within the vendored upstream chart. As previously noted, modifications to vendored charts should not be made directly—they will drift from upstream and be overwritten during the next chart sync. Apply this change through the proper chart vendoring/update flow or a supported overlay mechanism instead. Based on learnings: Do NOT directly edit upstream Helm charts in vendored charts directory; use proper chart vendoring mechanisms.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/.helmignore`
around lines 24 - 26, You edited a vendored chart's .helmignore by adding
CHANGELOG.md/_changelog.md/_index.md; revert that direct edit in the vendored
chart (.helmignore) and instead apply the desired ignore changes via the chart
vendoring/update flow or an overlay: restore the vendored chart to upstream
state, then either update the vendored chart properly (run the repo's chart
vendoring command or helm dependency update to pull the upstream .helmignore) or
implement the change via a supported overlay mechanism (e.g., use your
repository's chart overlay/patch system or CI vendoring scripts to inject
.helmignore changes during vendor generation) so upstream updates won't be
overwritten.

packages/core/platform/values.yaml (1)

8-9: ⚠️ Potential issue | 🔴 Critical

Bump the migrations image together with targetVersion.

Line 9 advances the platform to migration 36, but Line 8 still pins an immutable platform-migrations:v1.1.0@sha256:... image. That image cannot contain packages/core/platform/images/migrations/migrations/35, so the 35→36 upgrade path is still broken until both values move together.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/core/platform/values.yaml` around lines 8 - 9, The targetVersion was
bumped to 36 but the immutable image field still points to
platform-migrations:v1.1.0@sha256:..., so the migrations image must be updated
in tandem; update the image value (the "image" entry) to a new tag/sha that
contains the 35→36 migration (the release that corresponds to targetVersion 36)
so the migrations image and targetVersion remain in sync.

packages/core/platform/images/migrations/migrations/35 (1)

1-1: ⚠️ Potential issue | 🔴 Critical

Make this script POSIX-safe or switch it to Bash.

set -euo pipefail is not portable under the #!/bin/sh shebang on Line 1, and Lines 20-21 rely on that pipeline behavior to surface kubectl create failures. This is the same portability bug raised earlier and it is still present.

POSIX-safe fix

 #!/bin/sh
@@
-set -euo pipefail
+set -eu
@@
-kubectl create configmap --namespace cozy-system cozystack-version \
-  --from-literal=version=36 --dry-run=client --output yaml | kubectl apply --filename -
+tmpfile="$(mktemp)"
+trap 'rm -f "$tmpfile"' EXIT
+
+kubectl create configmap --namespace cozy-system cozystack-version \
+  --from-literal=version=36 --dry-run=client --output yaml >"$tmpfile"
+kubectl apply --filename "$tmpfile"

#!/bin/bash
set -eu

echo "== Migration 35 shebang / shell options / pipeline =="
sed -n '1,25p' packages/core/platform/images/migrations/migrations/35

echo
echo "== Compare with nearby bash-based migrations, if present =="
for n in 28 29 30; do
  f="packages/core/platform/images/migrations/migrations/$n"
  if [ -f "$f" ]; then
    echo "--- $f ---"
    sed -n '1,8p' "$f"
  fi
done

echo
echo "== Migrations image build files =="
fd 'Dockerfile|Containerfile' packages/core/platform/images/migrations -x sh -c '
  echo "--- $1 ---"
  sed -n "1,80p" "$1"
' sh {}

Also applies to: 8-8, 20-21

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/core/platform/images/migrations/migrations/35` at line 1, The script
uses a non-portable set -euo pipefail under #!/bin/sh and its kubectl pipeline
on Lines 20-21 relies on pipefail; either change the shebang to a Bash
interpreter (e.g. #!/usr/bin/env bash) and keep set -euo pipefail, or make the
script POSIX-safe by replacing set -euo pipefail with set -eu and rewriting the
piped kubectl create sequence (the commands on Lines 20-21) to explicitly check
and propagate the kubectl exit status (e.g., capture/check exit codes or use a
conditional/brace block) so failures are surfaced without relying on pipefail.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/role.yaml (1)

17-32: ⚠️ Potential issue | 🟠 Major

Split create out of the resourceNames-scoped CRD rule.

resourceNames does not authorize top-level CRD creates, so this hook role can't create missing CRDs when upgrade mode is enabled. Keep create in its own rule without resourceNames, and keep the named restriction on the non-create verbs.

Suggested fix

 rules:
+  - apiGroups:
+      - "apiextensions.k8s.io"
+    resources:
+      - "customresourcedefinitions"
+    verbs:
+      - create
   - apiGroups:
       - "apiextensions.k8s.io"
     resources:
       - "customresourcedefinitions"
     verbs:
-      - create
       - patch
       - update
       - get
       - list
     resourceNames:
       {{- range $crds }}
         {{- $crd := fromYaml . }}
       - {{ $crd.metadata.name }}
       {{- end }}

Can Kubernetes RBAC `resourceNames` restrict top-level `create` requests for `customresourcedefinitions`, or must `create` be granted in a separate rule without `resourceNames`?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/templates/role.yaml`
around lines 17 - 32, The RBAC rule currently ties the "create" verb to a rule
that includes resourceNames, which does not allow creating new top-level
customresourcedefinitions; split the rules so that one rule for apiGroups
"apiextensions.k8s.io" and resources "customresourcedefinitions" lists only the
verb "create" (no resourceNames), and keep a separate rule with the same
apiGroups/resources that includes the non-create verbs (patch, update, get,
list) plus the resourceNames block populated from the {{- range $crds }} ... {{-
end }} loop; update the rules array to include both entries so create can
operate cluster-wide while other verbs remain name-scoped.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/server.yaml (1)

4-7: Unused $env variable.

The $env dict is built by iterating over .Values.env but is never used in the template. The env vars are rendered directly via range .Values.env on lines 57-60. Consider removing this unused code.

Suggested fix

 {{- $ctx := dict "helm" . "noEnterprise" true }}
 {{- $fullname := include "vm.plain.fullname" $ctx }}
 {{- $ns := include "vm.namespace" $ctx }}
-{{- $env := dict -}}
-{{- range .Values.env | default list -}}
-  {{- $_ := set $env .name .value -}}
-{{- end -}}
 ---

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/server.yaml`
around lines 4 - 7, The template builds an unused dict named $env by iterating
.Values.env (the block that defines {{- $env := dict -}} and the subsequent
range/set), which is redundant because the template later renders environment
variables directly from .Values.env; remove the entire $env creation block (the
lines that create and populate $env) or alternatively change the env rendering
to iterate over $env instead—preferably delete the unused $env block to
eliminate dead code.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/values.yaml (1)

9-11: Consider pinning the busybox image tag for reproducibility.

Using tag: latest for the busybox image can lead to unpredictable behavior across deployments and makes builds non-reproducible. Consider pinning to a specific version.

Suggested fix

   busybox:
     image:
       repository: busybox
-      tag: latest
+      tag: "1.36"
       pullPolicy: IfNotPresent

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/crds/values.yaml`
around lines 9 - 11, The values.yaml currently sets repository: busybox and tag:
latest which makes image pulls non-reproducible; update the tag field to a
specific pinned BusyBox version (e.g., replace tag: latest with a concrete
semver like tag: "1.xx.x") and keep pullPolicy: IfNotPresent (or change to
IfNotPresent only if you want cached behavior), ensuring the repository and tag
fields in the CRD values are updated together so deployments use a fixed BusyBox
image version.