[tests] Fix test by kvaps · Pull Request #753 · cozystack/cozystack

Andrei Kvapil (kvaps) · 2025-04-03T14:55:01Z

This PR fixes error on installing monitoring application:

  Warning  InstallFailed     3m55s  helm-controller  Helm install failed for release tenant-root/monitoring with chart monitoring@1.9.1: 1 error occurred:
           * Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": failed to call webhook: Post "https://root-ingress-controller-admission.tenant-root.svc:4
43/networking/v1/ingresses?timeout=10s": dial tcp 10.96.101.2:443: connect: operation not permitted

Summary by CodeRabbit

New Features
- Introduced conditional dependency management for the ingress service, enhancing deployment order when enabled.
- Added support for additional configuration options, including allowed metrics endpoints and pod security context settings.
Chores
- Updated the application version from 1.9.1 to 1.9.2.
- Refined version tracking entries to align with the latest release.
- Expanded service monitor configuration options for better flexibility in monitoring setups.

coderabbitai · 2025-04-03T14:55:10Z

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This pull request updates the tenant application’s version from 1.9.1 to 1.9.2 and adjusts the related version mapping. In addition, a conditional block has been added to the monitoring template that, when enabled by the .Values.ingress flag, injects a dependency on an ingress resource into the HelmRelease configuration.

Changes

File(s)	Change Summary
`.../tenant/Chart.yaml` `.../versions_map`	Updated tenant version from 1.9.1 to 1.9.2; replaced the commit hash for version 1.9.1 with `de19450f` in the versions map and added a new entry for 1.9.2.
`.../tenant/templates/monitoring.yaml`	Introduced a conditional block that adds a `dependsOn` field with a dependency on the ingress resource when `.Values.ingress` is true.

Sequence Diagram(s)

sequenceDiagram
    participant Values as .Values
    participant Template as Helm Template
    participant Release as HelmRelease Object
    participant Ingress as Ingress Resource

    Values->>Template: Evaluate .Values.ingress
    alt ingress enabled
        Template->>Release: Inject dependsOn: ingress
        Release->>Ingress: Declare dependency
    else
        Template-->>Release: Proceed without dependency
    end

Poem

Oh, I’m a rabbit with a coding beat,
Leaping through versions with happy feet.
A little tweak here, a snippet there,
Dependencies added with utmost care.
I hop with joy in this updated spree,
This change makes the Helm dance with glee!

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai plan to trigger planning for file edits and PR creation.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (1)

hack/e2e.sh (1)

316-316: Updated Timeout for HelmRelease Readiness

Increasing the timeout duration from 2 minutes to 5 minutes provides additional leeway for HelmReleases in the tenant-root namespace to stabilize during end-to-end tests. This change addresses the reported timeout issues. For future flexibility, consider parameterizing the timeout duration via an environment variable or configuration file if your deployment environments vary significantly in startup times.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between de19450 and 0241e56.

📒 Files selected for processing (1)

hack/e2e.sh (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (1)

GitHub Check: Build and Test for Pull Requests

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (1)

hack/e2e.sh (1)

316-316: Increased Timeout for HelmRelease Readiness

The adjustment of the timeout from "2m" to "5m" in this kubectl wait command is aligned with the PR objective of addressing timeout issues for tenant-root applications. This longer waiting period should help mitigate premature failures when HelmRelease resources take longer to become ready.

Please ensure that this increased delay does not adversely affect overall test execution time or mask underlying issues with resource startup. If these calls are part of a larger testing suite, consider documenting the rationale or even parameterizing the timeout value for greater flexibility in different environments.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between de19450 and 0241e56.

📒 Files selected for processing (1)

hack/e2e.sh (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (1)

GitHub Check: Build and Test for Pull Requests

coderabbitai

Actionable comments posted: 1

🧹 Nitpick comments (39)

packages/system/kamaji/charts/kamaji/Chart.yaml (1)

24-24: Dependency Version Update in kamaji-etcd
The dependency version for kamaji-etcd is updated to ">=0.9.2". Please verify that this update is compatible with the rest of the system and that corresponding documentation (e.g. README.md) reflects this change appropriately.

packages/system/capi-operator/charts/cluster-api-operator/templates/infra.yaml (1)

29-32: Conditional Helm Hook Annotation for Namespace (Infra)
A conditional block has been added to include Helm hook annotations ("helm.sh/hook" and "helm.sh/hook-weight") if enableHelmHook is true. Please double-check the YAML indentation here as YAMLlint indicates a potential indentation issue on line 30.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

packages/system/capi-operator/charts/cluster-api-operator/templates/control-plane.yaml (1)

29-32: Conditional Helm Hook Annotation for Namespace (Control Plane)
Similar to the infra template, the Namespace definition now conditionally applies Helm hook annotations based on enableHelmHook. Please review the YAML indentation for consistency, as minor indentation issues may affect YAML parsing.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)
packages/system/capi-operator/charts/cluster-api-operator/templates/addon.yaml (2)
29-32: YAML Indentation in Namespace Annotations
YAMLlint reports a warning on these lines (expected indentation of 2 but found 4). The conditional block for the Helm hook annotations should be indented consistently to comply with YAML best practices.

Consider applying a diff like:
-    {{- if $.Values.enableHelmHook }}
-    "helm.sh/hook": "post-install,post-upgrade"
-    "helm.sh/hook-weight": "1"
-    {{- end }}
+  {{- if $.Values.enableHelmHook }}
+    "helm.sh/hook": "post-install,post-upgrade"
+    "helm.sh/hook-weight": "1"
+  {{- end }}
This adjustment should resolve the warning.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

42-45: YAML Indentation in AddonProvider Annotations
Similarly, the conditional annotations in the AddonProvider block (lines 42–45) need a consistent indentation. Double-check that the rendered YAML meets the expected structure after templating.

A similar indentation adjustment may be needed here.
packages/system/kamaji/charts/kamaji/README.md (1)
25-25: Bare URL in Table Column
Markdownlint flagged the use of a bare URL on this line. For improved readability and to follow best practices, consider wrapping the URL in Markdown link syntax.

For example:
-| https://clastix.github.io/charts | kamaji-etcd | >=0.9.2 |
+| [https://clastix.github.io/charts](https://clastix.github.io/charts) | kamaji-etcd | >=0.9.2 |
This change will help satisfy MD034.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

25-25: Bare URL used
null

(MD034, no-bare-urls)
packages/system/capi-operator/charts/cluster-api-operator/templates/ipam.yaml (2)
29-32: YAML Indentation in Namespace Annotations (IPAM)
Similar to the addon template, YAMLlint warns about the indentation in this annotation block. Aligning the conditional block correctly will help prevent potential rendering issues.

A possible diff could be:
-    {{- if $.Values.enableHelmHook }}
-    "helm.sh/hook": "post-install,post-upgrade"
-    "helm.sh/hook-weight": "1"
-    {{- end }}
+  {{- if $.Values.enableHelmHook }}
+    "helm.sh/hook": "post-install,post-upgrade"
+    "helm.sh/hook-weight": "1"
+  {{- end }}
Review and adjust as needed.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

42-45: YAML Indentation in IPAMProvider Annotations
Ensure that the conditional Helm hook annotations for the IPAMProvider are indented consistently. This will avoid YAML lint issues and ensure proper YAML structure.
packages/system/capi-operator/charts/cluster-api-operator/templates/core-conditions.yaml (2)

9-13: YAML Indentation in Namespace Annotations (Core Components)
The conditional block for Helm hook annotations in the Namespace section should be verified for proper indentation. Running a helm template command can help confirm that the final output is correctly formatted.

22-26: YAML Indentation in CoreProvider Annotations
Likewise, check the indentation for the conditional annotations in the CoreProvider block. Consistent indentation is key for avoiding lint issues.

packages/system/kamaji/charts/kamaji/crds/kamaji.clastix.io_tenantcontrolplanes.yaml (1)

3464-3470: Hunk 46: CSI Description Enhancement

The updated description for csi explains that it represents ephemeral storage handled by external CSI drivers.
Suggestion: Consider clarifying whether this property also governs persistent volumes or strictly ephemeral storage.

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

9-13: Metadata Context Handling
Using the $ctx variable with inline set and unset operations for extraLabels cleans up metadata label management. Verify that $pdb.labels is consistently defined in your values.

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

1-8: CRD Cleanup Image Tag Handling
The conditional logic for setting the image tag is robust. It calculates a tag based on the Kubernetes version if none is provided and fails early if the tag is not a string. Consider verifying that the computed tag (using KubeVersion values) always conforms to your image tagging conventions.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

[warning] 5-5: wrong indentation: expected 0 but found 2

(indentation)

[warning] 7-7: wrong indentation: expected 0 but found 2

(indentation)

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

8-12: Metadata Consolidation with Updated Variables

The updates in the metadata section—using {{ $fullname }}, {{ $ns }}, and incorporating extraLabels with set/unset operations—improve consistency. Verify that unsetting extraLabels in $ctx does not inadvertently remove labels needed later in the template.

139-141: Priority ClassName Injection

Introducing the priorityClassName block is a useful enhancement for scheduling priorities. Ensure that .Values.priorityClassName is properly documented and validated in your values schema.

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

326-335: Native Histogram Minimum Bucket Factor Update

Allowing nativeHistogramMinBucketFactor to be specified as either an integer or string (with a validation pattern) is a flexible enhancement. Double-check that the regex pattern fully captures the valid range of growth factors expected in your environment.

packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-servicemonitors.yaml (3)

1018-1028: Addition of Fallback Scrape Protocol Field
A new field fallbackScrapeProtocol has been introduced with detailed documentation and enum options. This addition allows for graceful handling when the scraped content type is invalid. Please verify that downstream Prometheus configurations or documentation are updated to reference this new field and that the Prometheus version in use (>= v3.0.0) supports it.

1096-1105: Native Histogram Minimum Bucket Factor Field Added
This field accepts either an integer or a string, with an explicit regex pattern for validation. Verify that the pattern works as intended and that users are informed of the requirement (Prometheus >= v2.50.0) for this setting.

1137-1149: Update to Scrape Protocols Enumeration
The enum for scrapeProtocols has been updated to include PrometheusText1.0.0, ensuring the list of supported protocols is comprehensive. Please double-check that the displayed list in the description aligns with the enum values.

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

195-196: Priority Class Configuration
The new key priorityClassName allows users to specify pod scheduling priorities. An empty default is acceptable, but consider documenting its usage further to guide users in high-priority environments.

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

200-200: YAML Formatting – Trailing Spaces Detected
Static analysis detected trailing spaces (line 200). Please remove any extraneous whitespace to adhere to YAML linting standards.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 200-200: trailing spaces

(trailing-spaces)

packages/system/cilium/charts/cilium/templates/spire/server/service.yaml (1)

8-13: Merge of Common and Service-Specific Labels & YAML Indentation Check
The new blocks correctly merge labels from both .Values.commonLabels and .Values.authentication.mutual.spire.install.server.service.labels under the Service’s metadata. However, YAMLlint reports warnings concerning the indentation (e.g. lines 10–13 expected 2 spaces but found 4). Please verify that using nindent 4 here produces the intended YAML structure. If the rendered YAML appears misaligned, consider adjusting the indentation (for example, using nindent 2) to meet YAML conventions.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 10-10: wrong indentation: expected 2 but found 4

(indentation)

[warning] 11-11: wrong indentation: expected 2 but found 4

(indentation)

[warning] 12-12: wrong indentation: expected 2 but found 4

(indentation)

[warning] 13-13: wrong indentation: expected 2 but found 4

(indentation)

packages/system/cilium/charts/cilium/templates/spire/server/statefulset.yaml (2)

16-23: Labels Merging Consistency & Indentation
In the StatefulSet metadata, the labels block now appends entries from both .Values.commonLabels and .Values.authentication.mutual.spire.install.server.labels (lines 18–23). This aligns with the overall strategy of centralizing label management. However, note that in the Service template, the corresponding server-specific key is .Values.authentication.mutual.spire.install.server.service.labels rather than .Values.authentication.mutual.spire.install.server.labels. Please confirm that this difference is intentional and that it correctly reflects the desired configuration for each resource. Additionally, verify that using nindent 4 here achieves the correct YAML layout.

32-39: Pod Template Labels Indentation Check
Within the pod template metadata (lines 32–39), the labels merging uses nindent 8 to account for deeper nesting. Ensure that this further indentation is consistent with the output of the StatefulSet’s pod spec. A quick manual render of the template may help verify that the final YAML is valid and as expected.

packages/system/cilium/charts/cilium/values.schema.json (2)

522-529: Review Comment: Distributed LRU Configuration

The new "distributedLRU" property is well defined as an object with an "enabled" flag of type boolean. This addition will allow users to toggle the distributed LRU caching behavior.

Suggestion: Consider adding a "default" attribute or including descriptive metadata (like a "description" field) in the schema to clarify the intended default state and usage expectations.

5479-5481: Review Comment: Tunnel Source Port Range

The "tunnelSourcePortRange" property is introduced as a string. This property likely allows users to specify a range (with a default of "0-0" in the corresponding YAML) for choosing tunnel source ports.

Suggestion: Consider enforcing a specific pattern (via a "pattern" key in JSON Schema) that validates the expected format (e.g., "^\d+-\d+$") to prevent misconfiguration.

packages/system/cilium/charts/cilium/templates/cilium-operator/rolebinding.yaml (1)

10-14: Optimize Metadata Labels Merge
The updated labels section now explicitly adds the fixed label
app.kubernetes.io/part-of: cilium before merging in .Values.commonLabels.
Please verify that in cases where the common labels already define this key, the intended merge order is preserved.

packages/system/cilium/charts/cilium/README.md (3)

134-135: New Distributed LRU Configuration:
New keys for bpf.distributedLRU (line 134) and bpf.distributedLRU.enabled (line 135) have been introduced. Confirm that the default “false” setting is as intended and consider adding further documentation about its impact on BPF map performance if not already covered in external docs.

897-897: Tunnel Source Port Range Configuration:
On line 897, the tunnelSourcePortRange is now set to “0-0”, allowing the kernel driver to determine the port range. Confirm that this behavior is clearly documented in usage guides and that it meets your deployment requirements without introducing unexpected port assignments.

894-894: Markdown Formatting Improvement:
A static analysis tool flagged a bare URL on line 894. To resolve the MD034 warning, consider wrapping the URL in angle brackets or converting it to a markdown link (e.g. [link text](URL)).

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

894-894: Bare URL used
null

(MD034, no-bare-urls)

hack/e2e.sh (1)

350-352: Extended Timeout for Keycloak Helm Releases
The new command increases the timeout to 120 seconds before checking for the existence of helm releases in the cozy-keycloak namespace. This can help accommodate slower deployments. Consider adding a log message (or redirecting stderr) if the condition is not met in time so that debugging becomes easier.

packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_keycloakrealms.yaml (3)

135-139: Introduce Field: adminEventsExpiration
A new field adminEventsExpiration has been added under realmEventConfig. This field, which defines the expiration (in seconds) for admin events, will help control long‐term event data retention. Make sure that the operator’s cleanup routines account for this new setting and that appropriate validations are added downstream.

156-290: New SMTP Configuration Block
A comprehensive SMTP configuration section has been introduced. It defines nested properties for both connection (including authentication details via configMapKeyRef/secretKeyRef) and email template settings. Please ensure that:
• Sensitive values (like passwords) are referenced via secrets.
• The TODO hints (e.g. “TODO: Add other useful fields…”) are addressed or tracked for later improvements.
• Downstream code that uses these settings is updated to handle these nested objects appropriately.

395-520: Added userProfileConfig Section
The CRD now supports an extensive userProfileConfig block for configuring user profile attributes and groups in the realm. This includes nested properties for annotations, display names, groups, multivalued indicators, permissions (with separate “edit” and “view” sub-fields), and validations. Due to the complexity:
• Verify that the schema remains backward compatible with existing CRs.
• Consider adding default validations in the operator to ensure that required sub-properties are provided.
• Update the CRD documentation to clearly explain how unmanaged attributes are handled.

packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_keycloakclients.yaml (1)

68-75: AuthenticationFlowBindingOverrides Block
The new authenticationFlowBindingOverrides property for client auth flow overrides (with sub-fields for browser and directGrant) provides flexibility in authentication configuration. Verify that these overrides are consumed correctly by the downstream authentication logic.

packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_clusterkeycloakrealms.yaml (3)

130-134: Cluster Version of adminEventsExpiration
As with the namespaced realm CRD, adminEventsExpiration has been added for clusters. Confirm that event cleanup for cluster realms respects this configuration so that stale events are purged appropriately.

157-289: SMTP Configuration Consistency in Cluster CRD
The cluster-level CRD now includes an SMTP configuration block almost identical to that in the namespaced realm. Please verify that both CRDs remain in sync regarding the email configuration and that any differences between cluster and namespace scopes (if intentional) are clearly documented.

386-521: Enhanced userProfileConfig for Clusters
The new userProfileConfig section mirrors the one added for namespaced realms and introduces complex nested properties for attributes and groups. As with the other CRD:
• Ensure that validations and required fields are correctly enforced by the operator.
• Update the usage documentation to help users configure profile settings correctly within the cluster context.

packages/system/keycloak-operator/charts/keycloak-operator/_crd_examples/keycloakrealm.yaml (1)

80-97: Expanded SMTP Settings

The SMTP configuration has been expanded to include both a template and connection settings. Note that the "from" field is set to "frm@mailcom" which may be a placeholder or a typo; consider using a properly formatted email address (e.g., "frm@mail.com"). Ensure these SMTP settings are validated with your deployment environment.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b5b974f and 4e36502.

⛔ Files ignored due to path filters (4)

packages/system/kamaji/charts/kamaji/Chart.lock is excluded by !**/*.lock
packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/Chart.lock is excluded by !**/*.lock
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/Chart.lock is excluded by !**/*.lock
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/Chart.lock is excluded by !**/*.lock

📒 Files selected for processing (88)

hack/e2e.sh (1 hunks)
packages/apps/tenant/Chart.yaml (1 hunks)
packages/apps/tenant/templates/monitoring.yaml (1 hunks)
packages/apps/versions_map (1 hunks)
packages/system/capi-operator/charts/cluster-api-operator/Chart.yaml (1 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/addon.yaml (2 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/bootstrap.yaml (2 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/control-plane.yaml (2 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/core-conditions.yaml (2 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/core.yaml (3 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/infra-conditions.yaml (4 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/infra.yaml (3 hunks)
packages/system/capi-operator/charts/cluster-api-operator/templates/ipam.yaml (3 hunks)
packages/system/capi-operator/charts/cluster-api-operator/values.yaml (2 hunks)
packages/system/cilium/charts/cilium/Chart.yaml (2 hunks)
packages/system/cilium/charts/cilium/README.md (13 hunks)
packages/system/cilium/charts/cilium/files/cilium-envoy/configmap/bootstrap-config.yaml (2 hunks)
packages/system/cilium/charts/cilium/templates/cilium-agent/daemonset.yaml (3 hunks)
packages/system/cilium/charts/cilium/templates/cilium-agent/rolebinding.yaml (5 hunks)
packages/system/cilium/charts/cilium/templates/cilium-agent/service.yaml (1 hunks)
packages/system/cilium/charts/cilium/templates/cilium-configmap.yaml (9 hunks)
packages/system/cilium/charts/cilium/templates/cilium-operator/role.yaml (2 hunks)
packages/system/cilium/charts/cilium/templates/cilium-operator/rolebinding.yaml (3 hunks)
packages/system/cilium/charts/cilium/templates/hubble/servicemonitor.yaml (1 hunks)
packages/system/cilium/charts/cilium/templates/spire/server/service.yaml (1 hunks)
packages/system/cilium/charts/cilium/templates/spire/server/statefulset.yaml (1 hunks)
packages/system/cilium/charts/cilium/values.schema.json (3 hunks)
packages/system/cilium/charts/cilium/values.yaml (12 hunks)
packages/system/cilium/charts/cilium/values.yaml.tmpl (4 hunks)
packages/system/cilium/images/cilium/Dockerfile (1 hunks)
packages/system/kamaji/charts/kamaji/Chart.yaml (1 hunks)
packages/system/kamaji/charts/kamaji/README.md (2 hunks)
packages/system/kamaji/charts/kamaji/README.md.gotmpl (1 hunks)
packages/system/kamaji/charts/kamaji/crds/kamaji.clastix.io_tenantcontrolplanes.yaml (60 hunks)
packages/system/kamaji/images/kamaji/Dockerfile (1 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/Chart.yaml (2 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/README.md (2 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/README.md.gotmpl (1 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/_crd_examples/keycloakclient.yaml (3 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/_crd_examples/keycloakrealm.yaml (1 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_clusterkeycloakrealms.yaml (4 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_keycloakclients.yaml (5 hunks)
packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_keycloakrealms.yaml (4 hunks)
packages/system/kubeovn/Makefile (1 hunks)
packages/system/kubeovn/charts/kube-ovn/Chart.yaml (1 hunks)
packages/system/kubeovn/charts/kube-ovn/values.yaml (1 hunks)
packages/system/kubeovn/images/kubeovn/Dockerfile (1 hunks)
packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/Chart.yaml (2 hunks)
packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-podmonitors.yaml (10 hunks)
packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-probes.yaml (6 hunks)
packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-prometheusrules.yaml (4 hunks)
packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-servicemonitors.yaml (8 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/.helmignore (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/CHANGELOG.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/Chart.yaml (2 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/README.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/README.md.gotmpl (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/RELEASE_NOTES (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/RELEASE_NOTES.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/_changelog.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/_index.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/.helmignore (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/CHANGELOG.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/Chart.yaml (2 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/RELEASE_NOTES (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/RELEASE_NOTES.md (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_enterprise.tpl (2 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_helpers.tpl (6 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_image.tpl (2 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_pod.tpl (4 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_service.tpl (3 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/values.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/NOTES.txt (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/_helpers.tpl (2 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/cleanup.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/crb.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/crd.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/deployment.yaml (4 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/extra-objects.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/monitor.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/pdb.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/rb.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/role.yaml (5 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service_account.yaml (1 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service_scrape.yaml (0 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/webhook.yaml (3 hunks)
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/values.yaml (9 hunks)

💤 Files with no reviewable changes (9)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/_index.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/RELEASE_NOTES.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/CHANGELOG.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/_changelog.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/README.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service_scrape.yaml
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/CHANGELOG.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/RELEASE_NOTES.md
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/README.md.gotmpl

✅ Files skipped from review due to trivial changes (14)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/.helmignore
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/RELEASE_NOTES
packages/system/cilium/images/cilium/Dockerfile
packages/system/capi-operator/charts/cluster-api-operator/Chart.yaml
packages/system/cilium/charts/cilium/Chart.yaml
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/Chart.yaml
packages/system/kubeovn/Makefile
packages/system/kubeovn/charts/kube-ovn/values.yaml
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/RELEASE_NOTES
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/values.yaml
packages/system/kubeovn/images/kubeovn/Dockerfile
packages/system/kubeovn/charts/kube-ovn/Chart.yaml
packages/system/keycloak-operator/charts/keycloak-operator/README.md.gotmpl
packages/system/keycloak-operator/charts/keycloak-operator/README.md

🚧 Files skipped from review as they are similar to previous changes (3)

packages/apps/tenant/Chart.yaml
packages/apps/versions_map
packages/apps/tenant/templates/monitoring.yaml

🧰 Additional context used

🪛 LanguageTool

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/NOTES.txt

[uncategorized] ~1-~1: Loose punctuation mark.
Context: {{ include "vm.name" . }} has been installed. Check its status b...

(UNLIKELY_OPENING_PUNCTUATION)

🪛 GitHub Actions: Pull Request

packages/system/kamaji/images/kamaji/Dockerfile

[warning] 1-1: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1)

[warning] 14-14: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 14)

[warning] 2-2: FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value 'linux/amd64' (line 2)

[warning] 1-1: FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1)

[error] 1-1: failed to solve: failed to resolve source metadata for docker.io/library/golang:1.23-bookworm: failed to copy: httpReadSeeker: failed open: unexpected status code https://registry-1.docker.io/v2/library/golang/manifests/sha256:e0a49312dbe1950f9964ae0c7cec26eee8371a7d4aa8b5b97eadd3aed238a5e1: 429 Too Many Requests - Server message: toomanyrequests: You have reached your unauthenticated pull rate limit.

🪛 YAMLlint (1.35.1)

packages/system/capi-operator/charts/cluster-api-operator/templates/infra.yaml

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

packages/system/capi-operator/charts/cluster-api-operator/templates/ipam.yaml

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

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

[warning] 6-6: cannot infer indentation: unexpected token

(indentation)

[warning] 9-9: wrong indentation: expected 0 but found 2

(indentation)

[warning] 10-10: wrong indentation: expected 0 but found 2

(indentation)

[warning] 11-11: wrong indentation: expected 0 but found 2

(indentation)

[warning] 12-12: wrong indentation: expected 0 but found 2

(indentation)

[warning] 13-13: wrong indentation: expected 0 but found 2

(indentation)

[warning] 14-14: wrong indentation: expected 0 but found 2

(indentation)

[warning] 15-15: wrong indentation: expected 0 but found 4

(indentation)

[warning] 16-16: wrong indentation: expected 0 but found 4

(indentation)

[warning] 17-17: wrong indentation: expected 0 but found 6

(indentation)

packages/system/capi-operator/charts/cluster-api-operator/templates/core-conditions.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/capi-operator/charts/cluster-api-operator/templates/core.yaml

[warning] 29-29: wrong indentation: expected 2 but found 4

(indentation)

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

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

[warning] 5-5: wrong indentation: expected 0 but found 2

(indentation)

[warning] 7-7: wrong indentation: expected 0 but found 2

(indentation)

packages/system/capi-operator/charts/cluster-api-operator/templates/control-plane.yaml

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/monitor.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/capi-operator/charts/cluster-api-operator/templates/bootstrap.yaml

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

packages/system/capi-operator/charts/cluster-api-operator/templates/addon.yaml

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

packages/system/cilium/charts/cilium/templates/hubble/servicemonitor.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/pdb.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/cilium/charts/cilium/templates/spire/server/service.yaml

[warning] 10-10: wrong indentation: expected 2 but found 4

(indentation)

[warning] 11-11: wrong indentation: expected 2 but found 4

(indentation)

[warning] 12-12: wrong indentation: expected 2 but found 4

(indentation)

[warning] 13-13: wrong indentation: expected 2 but found 4

(indentation)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service_account.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/deployment.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

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

[error] 200-200: trailing spaces

(trailing-spaces)

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

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

🪛 markdownlint-cli2 (0.17.2)

packages/system/kamaji/charts/kamaji/README.md

25-25: Bare URL used
null

(MD034, no-bare-urls)

packages/system/cilium/charts/cilium/README.md

894-894: Bare URL used
null

(MD034, no-bare-urls)

🔇 Additional comments (255)

packages/system/kamaji/images/kamaji/Dockerfile (1)

4-4: Build Argument VERSION Update
The build argument VERSION has been updated from edge-24.12.1 to edge-25.3.2. Confirm that this version upgrade is intentional and compatible with the source code being built. Additionally, note that CI pipeline errors regarding pull rate limits might require configuring Docker Hub credentials to avoid unauthenticated rate limiting.

packages/system/capi-operator/charts/cluster-api-operator/values.yaml (2)

24-24: Manager Image Tag Update
The manager image tag is updated to v0.18.1. Ensure that the new image version is fully tested for compatibility and that any breaking changes are accounted for in downstream deployments.

72-72: Enable Helm Hook Configuration Added
The addition of enableHelmHook: true provides a toggle for injecting Helm hook annotations across templates. Verify that this setting propagates to all dependent resources as intended and that the documentation is updated to explain its usage.

packages/system/capi-operator/charts/cluster-api-operator/templates/infra.yaml (2)

42-45: Conditional Helm Hook Annotation for InfrastructureProvider
The InfrastructureProvider’s metadata now conditionally includes Helm hook annotations with a hook weight of "2". This looks consistent with the overall design; just ensure that the rendered manifest meets your expectations in a cluster environment.

53-63: Dynamic Manager Feature Gates for InfrastructureProvider
The block that iterates over $.Values.manager.featureGates to dynamically apply feature gates for the current infrastructure is a welcome enhancement. Ensure that the provided feature gate keys and values are validated and that this dynamic configuration covers all necessary cases.

packages/system/capi-operator/charts/cluster-api-operator/templates/control-plane.yaml (2)

41-46: Conditional Helm Hook Annotation for ControlPlaneProvider
The ControlPlaneProvider metadata now conditionally includes Helm hook annotations with a hook weight of "2" and a sync-wave annotation. This implementation aligns with the pattern in other templates. Verify that the final manifest renders correctly and that the hook weight is appropriate for your deployment order.

53-64: Dynamic Manager Feature Gates for ControlPlaneProvider
The dynamic injection of feature gates based on the control plane provider’s name is implemented here. This enhances flexibility for custom configurations. Please ensure that the input structure for feature gates is properly validated and that the behavior has been verified in different deployment scenarios.

packages/system/capi-operator/charts/cluster-api-operator/templates/bootstrap.yaml (2)

29-33: LGTM: Well-structured conditional helm hooks with ArgoCD sync waves

The inclusion of conditional Helm hooks here is well-implemented, allowing flexibility in controlling the installation sequence when needed. The addition of ArgoCD sync wave annotations is also a good practice for ensuring proper synchronization order in GitOps workflows.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 30-30: wrong indentation: expected 2 but found 4

(indentation)

42-46: LGTM: Consistent conditional annotations

The conditional Helm hook annotations for the BootstrapProvider resource maintain consistency with the Namespace resource above. The approach properly ensures that post-install and post-upgrade hooks are only applied when explicitly enabled.

packages/system/kamaji/charts/kamaji/README.md.gotmpl (1)

21-29: LGTM: Improved installation instructions

Good addition of explicit instructions for adding the Clastix repository before installation. This helps users avoid common installation errors due to missing repositories.

packages/system/capi-operator/charts/cluster-api-operator/templates/infra-conditions.yaml (5)

10-14: LGTM: Well-structured conditional helm hooks

The implementation of conditional Helm hooks is well-designed, consistent with other templates, and improves deployment flexibility. The sync wave annotation helps ensure proper ordering in ArgoCD deployments.

23-27: LGTM: Consistent conditional annotations

The conditional approach to Helm hooks is consistently applied to the BootstrapProvider, maintaining a uniform pattern throughout the codebase.

44-48: LGTM: Consistent sync wave configuration

The Helm hook configuration for the control plane namespace follows the same pattern as other resources, ensuring consistent deployment sequencing.

57-61: LGTM: Properly structured annotations

The conditional annotations for the ControlPlaneProvider match the pattern used elsewhere, maintaining codebase consistency and enabling flexible deployment ordering.

66-66: LGTM: Consistent indentation for manager configuration

The indentation for the manager block is well-structured and consistent with the rest of the template.

packages/system/capi-operator/charts/cluster-api-operator/templates/core.yaml (3)

28-32: LGTM: Well-structured conditional helm hooks with ArgoCD integration

The conditional Helm hooks and ArgoCD sync wave annotations are consistently implemented, aligning with the pattern used in other templates.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 29-29: wrong indentation: expected 2 but found 4

(indentation)

41-45: LGTM: Consistent annotation pattern

The annotations for the CoreProvider follow the same conditional pattern as other resources, maintaining a uniform approach to deployment sequencing.

54-54: LGTM: Proper indentation for manager configuration

The manager configuration block is consistently formatted with the surrounding conditional checks.

packages/system/kamaji/charts/kamaji/README.md (2)

34-37: Repository Addition Instruction Clarity
The new instructions for adding the Clastix Helm repository are clearly stated. Ensure the code block formatting (as shown in lines 36–37) is retained during rendering for clarity in CLI usage.

40-40: Updated Installation Command
The installation command now explicitly specifies the release name “kamaji”, which improves clarity. No issues detected here.

packages/system/capi-operator/charts/cluster-api-operator/templates/ipam.yaml (1)

54-63: Dynamic Feature Gates Handling
The new implementation that loops over $.Values.manager.featureGates for the IPAM provider adds flexible configuration. The logic looks sound—please confirm via manual testing that it correctly picks up feature gates specific to the IPAM name. Adding a brief inline comment here might aid future maintainers.

packages/system/capi-operator/charts/cluster-api-operator/templates/core-conditions.yaml (1)

1-1: Helm Templating Syntax Warning
YAMLlint reports a syntax error on line 1 due to the templating directive. This is a common false positive with Helm templates. Just ensure that your Helm rendering engine processes these directives correctly during deployment.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/kamaji/charts/kamaji/crds/kamaji.clastix.io_tenantcontrolplanes.yaml (59)

497-503: Hunk 1: Update to Exec Description in Lifecycle Hooks

The added description now clearly states that the exec property specifies a command to execute in the container. This improves clarity for users reading the CRD documentation and aligns well with Kubernetes terminology.

512-518: Hunk 2: Clarification for HTTPGet Description in Lifecycle Hooks

The update to the httpGet description emphasizes that it performs an HTTP GET request. This precise wording helps avoid ambiguity.

559-565: Hunk 3: Update to Sleep Description

The new description for the sleep property clearly indicates that it represents the duration the container should sleep. This concise wording aids comprehension.

571-578: Hunk 4: Enhanced Deprecation Message for TCPSocket in Lifecycle Hooks

The modified description for tcpSocket now explicitly warns that it is deprecated, is maintained only for backward compatibility, and that lifecycle hooks will fail at runtime if used. This explicit messaging is very helpful.

603-609: Hunk 5: Consistent Exec Description Update

The update in this block reiterates that the exec field is used to specify a command in the container. The consistency across similar sections is beneficial.

618-623: Hunk 6: HTTPGet Description Update for Container Probes

The updated text for httpGet clearly indicates that it specifies an HTTP GET request. This description is now more self-explanatory.

665-671: Hunk 7: Consistent Update to Sleep Description

The description update for the sleep property is clear and matches the earlier update. This uniformity across the CRD enhances readability.

677-684: Hunk 8: Revised TCPSocket Deprecation Notice in Lifecycle Hooks

This hunk reiterates for another section that the tcpSocket property is deprecated for lifecycle hooks, explaining that there is no validation and that runtime failure will occur. The clarity here is useful.

705-711: Hunk 9: Exec Description Update in Container Probes

The update repeats the clear description for the exec property within the probe context. Keeping the message consistent is a good practice.

726-732: Hunk 10: GRPC Description Enhancement

The new description for the grpc property now specifies that it is used for a GRPC HealthCheckRequest, along with the constraints on port numbers. This precise wording is beneficial.

744-750: Hunk 11: HTTPGet Description Consistency

The updated description for httpGet remains clear and consistent with previous sections. This uniformity improves the overall documentation.

809-815: Hunk 12: TCPSocket Description in Probe Context

Here the description for tcpSocket now states that it “specifies a connection to a TCP port.” Unlike in lifecycle hooks, there is no deprecation warning in this context, which matches Kubernetes conventions.

911-917: Hunk 13: Exec Description Update for Pod Probes

The clear description update for exec in this section helps maintain consistency across different parts of the CRD.

932-938: Hunk 14: GRPC Description Refinement

The refinement in the grpc property description clearly communicates its functionality in health checks. The additional detail on port restrictions is useful.

950-956: Hunk 15: HTTPGet Description Reiteration

The revised description for httpGet continues to clearly state its purpose as performing an HTTP GET request. Maintaining this consistency is excellent.

1015-1021: Hunk 16: TCPSocket Description in Probe Section

The update clearly explains that tcpSocket is used for establishing a TCP connection, including the note on the host. This provides clear guidance to users.

1354-1360: Hunk 17: Exec Description Update for Additional Probe Section

The consistent wording for the exec description across multiple sections reinforces clarity and usability of the CRD documentation.

1375-1381: Hunk 18: GRPC Description Consistency

The update in this section for grpc is in line with similar changes elsewhere in the CRD. The description is clear and helpful.

1393-1399: Hunk 19: HTTPGet Description Consistency

The httpGet description update here is minor but maintains the uniform verbiage applied throughout the document.

1458-1464: Hunk 20: TCPSocket Description Revisited

The clear specification that tcpSocket establishes a TCP connection, with a note on default host handling, is consistent and clear.

1862-1868: Hunk 21: Exec Description within Lifecycle Hooks

The updated description for exec in this lifecycle hooks section is clear and leaves little room for misinterpretation.

1877-1883: Hunk 22: HTTPGet Description Update in Lifecycle Hooks

The update for the HTTPGet description here is consistent with other changes and clearly explains its purpose.

1924-1930: Hunk 23: Sleep Description Consistency

The refined description for the sleep property again emphasizes its role in specifying sleep duration, which is now clear and consistent.

1936-1943: Hunk 24: Updated Deprecation Notice for TCPSocket in Lifecycle Hooks

This hunk reiterates the deprecation and warns that lifecycle hooks will fail when tcpSocket is used. The message is explicit and consistent.

1968-1974: Hunk 25: Exec Description Reinforcement

The exec field description is again updated to maintain consistent language throughout the CRD, which is beneficial for documentation uniformity.

1983-1989: Hunk 26: HTTPGet Description Uniformity

The update keeps the HTTPGet description consistent with earlier sections. This makes the CRD easier to use and understand.

2030-2036: Hunk 27: Consistent Sleep Description Update

The changes for the sleep property in this section match those in similar contexts, ensuring clarity.

2042-2049: Hunk 28: TCPSocket Deprecation Notice Reiterated

The updated deprecation warning for tcpSocket here is clear and consistent with other lifecycle hook sections.

2070-2076: Hunk 29: Exec Description Consistency

The exec description update continues to deliver clear guidance throughout the CRD sections.

2091-2097: Hunk 30: GRPC Description Consistency

This update reaffirms the purpose of the grpc property along with the necessary port constraints. The language is clear.

2109-2115: Hunk 31: HTTPGet Description Standardization

The revised description for httpGet is consistent with previous sections, ensuring that the documentation remains uniform.

2174-2180: Hunk 32: TCPSocket Description Standardization in Probe Context

The description now clearly indicates that tcpSocket specifies a TCP connection, along with the appropriate handling of host names.

2276-2282: Hunk 33: Exec Description Standardization

The continued standardization of the exec description helps users easily understand its purpose across various contexts in the CRD.

2297-2303: Hunk 34: GRPC Description Reminder

The updated GRPC description remains concise and clear in specifying the health check request details.

2315-2321: Hunk 35: HTTPGet Description Uniformity

Another update to the httpGet description that reinforces its purpose; the consistency improves overall documentation coherence.

2380-2386: Hunk 36: TCPSocket Description Clarity

The updated description accurately reflects that tcpSocket is used for establishing a connection to a TCP port, with clear host configuration details.

2719-2725: Hunk 37: Exec Description in Additional Probe Context

The updated description for the exec property is consistent with similar sections and aids in clear understanding.

2740-2746: Hunk 38: GRPC Description Consistency

The GRPC description remains consistent, clearly stating its purpose and the required port range.

2758-2764: Hunk 39: HTTPGet Description for Container Probes

The revised description for httpGet continues to use consistent language, making the specification more uniform throughout the file.

2823-2829: Hunk 40: TCPSocket Description Consistency in Probe Section

This update reiterates that tcpSocket is used for TCP port connections, and the note on default host usage is clear.

3214-3221: Hunk 41: AWSElasticBlockStore Deprecation Message

The deprecation notice for AWSElasticBlockStore now explicitly advises that all operations are redirected to the CSI driver. This improved clarity helps guide users toward supported storage options.

3247-3256: Hunk 42: AzureDisk Deprecation Notice

The updated description for azureDisk succinctly explains the deprecation and redirection to the CSI driver. This clear message is very helpful.

3282-3291: Hunk 43: AzureFile Deprecation Update

The new description for azureFile clearly informs users about its deprecation and the migration to the CSI driver. Consistency with similar deprecation messages is maintained.

3303-3311: Hunk 44: CephFS Deprecation Clarification

The updated deprecation message for cephfs clearly states that it is no longer supported. It might be beneficial to mention any recommended alternatives if applicable.

3356-3363: Hunk 45: Cinder Deprecation Message

The description now clearly explains that the in-tree cinder type is deprecated and that operations are redirected to the CSI driver, along with a reference link for more details.

3906-3912: Hunk 47: FlexVolume Deprecation Notice

The revision to the flexVolume description now clearly indicates its deprecation and recommends using a CSIDriver instead. This clear guidance is very useful.

3950-3958: Hunk 48: Flocker Deprecation Message

The updated description for flocker details its deprecation and that it is no longer supported. It succinctly explains the dependency on the Flocker control service.

3967-3974: Hunk 49: GCEPersistentDisk Deprecation Clarification

The new deprecation message for gcePersistentDisk is clear and includes a reference link for more information, which is very helpful.

4004-4010: Hunk 50: GitRepo Deprecation Update

The deprecation notice now explicitly describes the alternative approach for provisioning a container with a git repository. This detailed guidance improves usability.

4027-4033: Hunk 51: Glusterfs Deprecation Notice

The updated description for glusterfs clearly states its deprecation and provides a URL for further guidance. This is a well-articulated update.

4234-4242: Hunk 52: PhotonPersistentDisk Deprecation Notice

The updated message clearly indicates that photonPersistentDisk is deprecated and unsupported, which helps in guiding users away from using it.

4251-4261: Hunk 53: PortworxVolume Deprecation Clarification

The detailed deprecation message for portworxVolume now explains the redirection to the CSI driver when the relevant feature gate is enabled. This level of detail is excellent.

4590-4598: Hunk 54: Quobyte Deprecation Notice

The updated description for quobyte clearly informs users about its deprecation, maintaining clarity and consistency within the document.

4630-4636: Hunk 55: RBD Deprecation Update

The deprecation message for rbd is now clear, with an added reference link to further documentation. This helps ensure users are well informed.

4703-4711: Hunk 56: ScaleIO Deprecation Clarification

The revised description for scaleIO accurately indicates its deprecation and includes its default configuration (xfs). This is clear and informative.

4831-4839: Hunk 57: StorageOS Deprecation Message

The updated description for storageos clearly states its deprecation and that it is no longer supported. This consistency is important for users.

4878-4887: Hunk 58: VsphereVolume Deprecation Notice

The revised description for vsphereVolume now explicitly states its deprecation and the redirection to the CSI driver. This update is concise and clear.

6836-6842: Hunk 59: PortStatus Description Update in Service Ports

The updated description for items in the Ports list now clearly explains that it represents the error condition of a service port. This added detail aids clarity.

7318-7324: Hunk 60: Consistency in PortStatus Description

The final hunk reiterates that each item in the Ports list represents the error condition of a service port. The uniformity in description across the document is excellent.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/_helpers.tpl (1)

25-26: Certificate naming convention updated correctly

The changes to the certificate generation logic properly migrate from the old naming pattern to the new vm.plain.fullname helper. This should ensure that webhooks receive properly formatted certificates with consistent naming, which is likely related to fixing the webhook admission issues mentioned in the PR objectives.

After deployment, verify that the webhook admission is working correctly by checking for successful connections to the webhook service.

Also applies to: 38-38, 43-43

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

23-24: Appropriate chart optimization

Adding markdown files to .helmignore is a good practice that reduces chart package size by excluding documentation that isn't needed for deployment.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/NOTES.txt (1)

1-1: Template naming consistency improved

Good change to use the template function vm.name instead of direct chart name reference. This ensures consistent naming throughout the chart and aligns with the broader refactoring of naming conventions.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~1-~1: Loose punctuation mark.
Context: {{ include "vm.name" . }} has been installed. Check its status b...

(UNLIKELY_OPENING_PUNCTUATION)

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

3-3: Improved type handling for extra objects

The change enhances flexibility by properly handling both string and non-string values in extraObjects. This is useful when users need to define both inline YAML structures and string templates, making the chart more robust and user-friendly.

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

4-4: Version update successfully reflects the latest Victoria Metrics Operator

The chart has been properly updated to reference the latest Victoria Metrics Operator version (v0.55.0) in both the appVersion field and annotations. The additional changelog link is a welcome improvement for users seeking to understand what's changed in this version.

This update may help resolve the dependency issues mentioned in the PR objectives if the previous version had webhook-related compatibility problems.

Also applies to: 13-14, 17-17, 45-45

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

4-8: Improved error handling for CRD configuration

The addition of the context variable and the explicit failure condition improves the template's error handling. The error message clearly explains why the configuration is invalid when CRDs are disabled but plain CRD rendering is enabled.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 6-6: cannot infer indentation: unexpected token

(indentation)

11-19: Enhanced CRD rendering with better structure

The updated approach to handling labels, annotations, and CRD attributes provides better structure and maintainability:

Using $ctx for labels provides consistency

Merging annotations with .Values.crds.annotations allows for customization

Iterating over attributes and outputting JSON format improves the consistency of the generated YAML

The YAMLlint warnings about indentation can be safely ignored as they're false positives for Helm templates.

🧰 Tools

🪛 YAMLlint (1.35.1)

[warning] 11-11: wrong indentation: expected 0 but found 2

(indentation)

[warning] 12-12: wrong indentation: expected 0 but found 2

(indentation)

[warning] 13-13: wrong indentation: expected 0 but found 2

(indentation)

[warning] 14-14: wrong indentation: expected 0 but found 2

(indentation)

[warning] 15-15: wrong indentation: expected 0 but found 4

(indentation)

[warning] 16-16: wrong indentation: expected 0 but found 4

(indentation)

[warning] 17-17: wrong indentation: expected 0 but found 6

(indentation)

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

2-12: Improved variable management with context

The introduction of a context dictionary for Helm values and the extraction of common variables improves code organization and maintainability. The proper handling of labels with set/unset operations on the context is a clean approach.

18-23: Enhanced service account and role reference handling

The updated approach for handling service account name with a fallback to $fullname and consistent namespace reference improves reliability. Using the pre-computed $fullname for the role reference name is also more efficient.

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

1-5: Variable Initialization and Conditional Check
The introduction of the $pdb variable and the conditional if $pdb.enabled improves template readability and centralizes configuration. Ensure that .Values.podDisruptionBudget is always defined (or has a default) to avoid runtime issues.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

15-22: Spec Section: Conditional Field Inclusion
The employment of with blocks for minAvailable and maxUnavailable ensures these fields are rendered only when provided. Double-check that any downstream consumers tolerate the absence of these fields when not set.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/monitor.yaml (7)

1-4: Service Monitor Context Initialization
Initializing the $monitor variable and merging annotations/extra labels with mustMerge enhances consistency. Confirm that the global .Values.annotations and .Values.extraLabels exist when not provided by the service monitor's configuration.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

5-7: Context Setup for Resource Naming
Creating $ctx, $fullname, and $ns centralizes resource naming and namespace assignment, which is a good abstraction.

8-9: Dynamic API Version and Kind Selection
The use of the ternary function for switching between API versions and kinds (based on $monitor.vm) is both clever and flexible. Please verify that the condition truly reflects the intended release strategy for the monitoring API.

10-15: Metadata and Label Management
The metadata section leverages context manipulation (set/unset) for incorporating extra labels. This approach is neat, but please double-check that label merging operates as expected across environments.

16-18: Conditional Annotations Inclusion
Using a conditional block to include annotations only when defined adds flexibility. This approach keeps the rendered YAML clean when annotations are absent.

19-44: Endpoint Configuration Block
The endpoints section is thoughtfully segmented using conditional with blocks for optional parameters (such as scheme, interval, scrapeTimeout, TLS configuration, relabeling, basicAuth, and proxy URL). Verify that the field names chosen via ternary (like "relabelConfigs" vs. "relabelings" and "proxyURL" vs. "proxyUrl") match the expected API for your monitoring service.

45-47: Namespace Selector Block
The namespace selector is correctly configured to match on the resource’s namespace. This is concise and clear.

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

9-11: Context Initialization for Cleanup Task
Initializing $ctx, $fullname, and $ns (with the noEnterprise flag) clarifies subsequent template references. This is a clean approach for multi-use resource naming in the job configuration.

12-19: Job Metadata Definition
The cleanup job’s metadata (name, namespace, labels, and annotations) is neatly templated. Confirm that the naming convention ({{ $fullname }}-cleanup-hook) and the inclusion of cleanup-specific annotations meet your operational requirements.

20-50: Pod Spec and Container Configuration
The pod specification is detailed, with conditional rendering for optional parameters such as imagePullSecrets, nodeSelector, affinity, and tolerations. The container definition (including dynamic setting of appKey and usage of include "vm.image") is well-structured.
Please verify that the use of toYaml combined with nindent consistently produces valid YAML.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service.yaml (4)

1-4: Service Variable Initialization
Introducing the $service variable improves clarity by centralizing all service-related configuration. This refactoring enhances maintainability.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

7-15: Service Metadata Configuration
The metadata section is now managed via a combination of with blocks and context manipulation (using extraLabels via set/unset). This is a clean approach, but please ensure that the global extra labels (.Values.extraLabels) reliably exist.

17-41: Service Spec Configuration
Conditional rendering for fields like clusterIP, externalIPs, loadBalancerIP, and others is implemented in a readable manner. It remains important to validate that the output indentation (using toYaml and nindent) produces valid YAML for each optional field.

42-50: Ports and Selector Setup
The ports are clearly delineated between HTTP and webhook services. Ensure that the numerical values and names (e.g. {{ $service.servicePort }} and {{ $service.webhookPort }}) correctly reflect the intended endpoints, and that the selector labels (via include "vm.selectorLabels") are in sync with your deployable pods.

packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/Chart.yaml (2)

15-15: Version Updates in Chart.yaml
The changes to appVersion (now set to v0.81.0) and version (set to 19.0.0) clearly indicate a new release. Ensure these version numbers align with the overall product release strategy and other dependent charts.

Also applies to: 41-41

27-35: Maintainer Information Consistency
The maintainer entries have been updated with current contact information. Double-check that all emails and URLs are accurate and reflect current maintainers.

packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-prometheusrules.yaml (3)

1-1: Version updates look consistent with the upstream Prometheus Operator.

Ensuring alignment with v0.81.0 and the updated controller-gen annotation is important for compatibility.

Also applies to: 10-11

65-74: New “labels” field for PrometheusRule is well-defined.

These lines properly declare the object type and clarify usage notes for Prometheus >= 3.0.0.

If you plan to use these labels with older Prometheus versions, confirm that ignoring them will not cause any unexpected breakage.

93-99: “query_offset” field addition is properly annotated.

Specifying a valid duration pattern and requiring Prometheus >= 2.53.0 is consistent. Verify that your cluster’s Prometheus meets this minimum version to avoid runtime issues.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_pod.tpl (5)

27-33: Security context handling improved.

The security context handling has been refactored to be more maintainable:

Always omitting "enabled" key upfront

Consolidating the removal of OpenShift-incompatible fields in one operation

Simplified output without conditional enabled flag checks

75-79: Improved HTTP probe scheme logic.

The HTTP probe scheme determination has been refactored with better readability:

Introduced an explicit $isSecure variable for clarity

Properly using string conversion with toString for robust comparison

Simplified the final ternary expression

90-90: Enhanced argument value checking.

The condition now includes additional type checking to ensure .value is a string and verifies that .list is not "true". This handles edge cases better and prevents potential errors when processing different value types.

95-95: Improved command-line argument formatting.

The formatting logic has been enhanced to:

Correctly use single (-) or double (--) dashes based on key length

Format values appropriately based on their type (maps, slices, etc.)

110-110: Updated list argument handling.

The argument handling for list values now correctly passes the "list" parameter as true, aligning with the changes made to the vm.arg function.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/service_account.yaml (4)

1-5: Better variable organization.

Variables are now defined at the beginning of the template, improving readability and reducing repeated function calls:

$ctx creates a consistent context dictionary

$fullname provides the resource name

$ns centralizes namespace handling

$sa simplifies access to ServiceAccount values

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

9-12: Standardized metadata handling.

Metadata fields now use the defined variables and improved helper functions:

Name falls back to $fullname if not specified

Namespace uses the centralized $ns variable

Labels use the updated vm.labels helper with proper context

16-16: Security enhancement: Explicit token mounting control.

The addition of explicit automountServiceAccountToken control is a security best practice, allowing users to specify whether the service account token should be automatically mounted in pods.

18-18: Improved conditional for cleanup ServiceAccount.

The condition now checks for both .Values.crds.enabled AND .Values.crds.cleanup.enabled, ensuring that cleanup hooks are only created when both conditions are met.

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

1-3: Consistent variable management.

Variables are defined at the beginning as in other templates, improving consistency and readability across files:

$ctx creates a consistent context dictionary

$fullname provides the resource name

$ns centralizes namespace handling

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

8-11: Standardized metadata handling.

Metadata fields now use the defined variables and improved helper functions:

Name uses the $fullname variable

Labels use the updated vm.labels helper with proper context

Context is properly cleaned up after use

24-24: Improved conditional for cleanup ClusterRoleBinding.

The condition now checks for both .Values.crds.enabled AND .Values.crds.cleanup.enabled, ensuring that cleanup hooks are only created when both conditions are met.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/deployment.yaml (6)

1-3: Context Variables Initialization

The definition of the context variable $ctx along with $fullname and $ns is clear and well-organized. Note that the YAML linter may flag the Helm templating syntax (e.g. the leading {{-) as a syntax error, but this can be safely ignored since it will render correctly.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

17-19: Replica Count and Selector Update

Using {{.Values.replicaCount}} for replicas and injecting vm.selectorLabels via the context variable ensure that the deployment selector is aligned with your new naming conventions. This looks correct.

26-27: Pod Labels Configuration

Injecting pod labels with {{ include "vm.podLabels" $ctx }} and subsequently unsetting the temporary extra labels ensures that pod metadata is kept clean. This approach is neat; please double-check that no unintended label data is lost.

29-29: Conditional Network and ServiceAccount Settings

The addition of the automountServiceAccountToken field and the conditional blocks for hostNetwork and serviceAccountName correctly reflect customizable deployment settings. Verify that the defaults in your values file align with these conditions.

Also applies to: 33-38

44-44: Container Image Update

Rendering the container image with {{ include "vm.image" $ctx }} leverages the context correctly. Just confirm that the vm.image template’s logic is consistent with your operator’s versioning strategy.

167-167: Volume Secret Name Consistency

The update to use {{ $fullname }} for defining the secret name ({{ $fullname }}-validation) in the volume mounts improves naming consistency throughout the chart.

packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-probes.yaml (7)

1-1: CRD Version Reference Update

Updating the reference comment to point to the Prometheus Operator CRD v0.81.0 ensures users are aware of the new version. This is a straightforward documentation improvement.

10-11: CRD Annotations Upgrade

The annotations for controller-gen.kubebuilder.io/version and operator.prometheus.io/version have been updated to v0.17.2 and 0.81.0, respectively. This aligns metadata with the updated operator version.

180-191: Fallback Scrape Protocol Field Addition

The new fallbackScrapeProtocol field is clearly documented and provides a well-defined enum of allowed protocol values. Please verify that these enum values match the ones supported in your target Prometheus version (>= v3.0.0).

319-325: Native Histogram Bucket Limit Configuration

The addition of the nativeHistogramBucketLimit field (with a requirement of Prometheus >= v2.45.0) is properly defined with an appropriate type and format. This helps in managing bucket merges in native histograms.

696-700: Scrape Classic Histograms Toggle

The new boolean field scrapeClassicHistograms allows operators to control whether classic histograms (exposed as native ones) are scraped. This is clearly documented, including the Prometheus version requirement (>= v2.45.0).

717-724: Scrape Protocols Enum Update

The inclusion of PrometheusText1.0.0 in the list of allowed scrape protocols—in both the inline documentation and the enum values—ensures consistency with protocol support. Confirm that all components in your monitoring stack recognize this protocol.

727-733: Scrape Timeout Validation Clarification

Appending the clarification that the scrapeTimeout value cannot exceed the scrape interval improves user guidance and prevents operator rejections. This explicit description is very helpful.

packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-podmonitors.yaml (10)

1-1: Updated Source URL Reference

The CRD example URL now points to Prometheus Operator v0.81.0. This update ensures that users refer to the latest example configuration.

10-11: Updated Annotation Versions

The annotations for controller-gen and the operator now reflect version v0.17.2 and 0.81.0 respectively. This ensures version consistency across the CRD resources.

84-95: Introduce fallbackScrapeProtocol Field

A new field fallbackScrapeProtocol has been added to specify the protocol to use when the scrape returns an invalid or blank Content-Type. The field is properly documented, including its enum values and the version requirement (Prometheus >= v3.0.0). Please ensure this change is consistent with other CRD definitions.

154-160: Add nativeHistogramBucketLimit Field

A new field nativeHistogramBucketLimit has been introduced to control the maximum number of buckets in a native histogram, with buckets being merged if the limit is exceeded. The field includes a clear description and version requirement (Prometheus >= v2.45.0).

161-170: Add nativeHistogramMinBucketFactor Field

A new field nativeHistogramMinBucketFactor has been added to enforce a minimum growth factor between histogram buckets. The use of anyOf to allow either integer or string types (with an appropriate regex pattern), plus the x-kubernetes-int-or-string indicator, helps maintain flexibility and strictness. The version requirement (Prometheus >= v2.50.0) is also provided.

778-787: Clarify Port Field Precedence and Constraints

The description for the port field now explicitly mentions that it takes precedence over portNumber and targetPort. Additionally, the portNumber field now includes explicit constraints (format, maximum, minimum) to ensure valid port values. This should help prevent misconfiguration.

906-906: Enforce Scrape Timeout Constraint

The updated documentation for scrapeTimeout now clearly states that its value cannot be greater than the scrape interval; otherwise, the operator will reject the resource. This clarification will improve configuration correctness.

917-917: Update Deprecation Notice for targetPort

The deprecation notice for the targetPort field now directs users to use the port or portNumber fields instead. This ensures consistency and guides users toward the preferred configuration options.

1108-1112: Introduce scrapeClassicHistograms Field

A new boolean field scrapeClassicHistograms has been added to determine whether a classic histogram (also exposed as a native histogram) should be scraped. The description specifies the Prometheus version requirement (>= v2.45.0), ensuring clarity on its applicability.

1186-1197: Add selectorMechanism Field for Endpoint Selection

A new field, selectorMechanism, has been added to offer an alternative strategy for selecting endpoints to scrape. It allows choosing between the default relabel configuration (RelabelConfig) and an opt-in role selection (RoleSelector), which could improve efficiency in large clusters. Ensure that this new option is well documented in your release notes and user guides to help administrators decide which strategy best fits their needs.

packages/system/victoria-metrics-operator/charts/prometheus-operator-crds/charts/crds/templates/crd-servicemonitors.yaml (4)

10-11: Version Annotation Update
The annotations for controller-gen.kubebuilder.io/version and operator.prometheus.io/version have been updated to match the Prometheus Operator version upgrade. This ensures the CRD reflects the correct tooling/versioning.

1089-1094: Native Histogram Bucket Limit Field Added
The new field nativeHistogramBucketLimit is clearly defined with a specified format. Ensure that consumers of this CRD are aware that buckets above this threshold will be merged, and that the required Prometheus version (>= v2.45.0) is in use.

1122-1127: Introduction of Scrape Classic Histograms Option
The new boolean field scrapeClassicHistograms provides flexibility in scraping both classic and native histograms. Its description and version requirement (Prometheus >= v2.45.0) are clear.

1200-1211: Addition of Selector Mechanism Field
The new selectorMechanism field offers a choice between using relabel configurations and role selectors for endpoint selection. This enhancement is useful in large clusters and its version requirement (Prometheus >= v2.17.0) is correctly documented.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/templates/webhook.yaml (6)

2-7: Refactoring with Context Variables
Introduction of the $ctx dictionary along with variables $tls, $fullname, $domain, $ns, and $certManager centralizes context and improves template readability. This refactor helps avoid repetitive code and simplifies maintenance.

12-17: Webhook Metadata and CA Injection Annotations Update
The metadata now uses the computed $fullname for naming ({{ $fullname }}-admission) and the CA injection annotations are updated to use the new $ns and $fullname variables. Ensure that these changes are consistent with your operator’s naming conventions and that the certificate management system recognizes the provided quotes.

20-30: Conditional CA Bundle Configuration
Within the webhook configuration, the clientConfig now conditionally injects caBundle based on the $certManager.enabled flag. This conditional logic is clear. It’s important to verify that when cert-manager is not enabled, $tls.caCert is correctly populated.

52-68: Issuer and Self-Signed Certificate Block
The issuer and the self-signed certificate issuance blocks (lines 52–68) introduce a flexible certificate management configuration by dynamically setting durations, subject, and secret templates. Double-check that the provided durations and subject parameters adhere to your security policies.

110-114: Dynamic IssuerRef Handling in Certificate Configuration
The block that sets up the $issuerRef is smartly checking if an issuer is provided; if not, it sets a default name based on $fullname. This is a good safeguard to ensure issuer consistency.

122-135: Fallback Secret Generation for Non-Cert-Manager Paths
If cert-manager is disabled, a Secret is created with essential TLS keys. This fallback ensures continuity. Make sure the keys (ca.crt, tls.crt, tls.key) are correctly sourced from $tls.

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

12-13: Cluster DNS Domain Update
The DNS domain value now includes a trailing period (cluster.local.), which is standard for fully qualified domain names. The accompanying comment adds useful context.

32-41: Enhanced CRD Configuration
Under the crds key, enabling CRD creation and allowing additional annotations are now explicitly defined. This improves CRD management and flexibility with regard to templated versus immutable CRDs.

74-77: New Allowed Metrics Endpoints Section
The addition of allowedMetricsEndpoints (with /metrics and /metrics/resources) provides finer control over permitted endpoints. Verify that these endpoints match those used in your monitoring configuration.

100-104: Pod Security Context Enhancements
New settings for fsGroup, runAsNonRoot, and runAsUser fortify the security posture of pods. This explicit definition contributes to best practices for container security.

107-113: Strengthened Security Context Settings
The securityContext now disables privilege escalation, drops all capabilities, and enforces a read-only root filesystem. These settings are aligned with security best practices for containerized deployments.

137-139: Service Account Token Auto-Mounting
Enabling automountServiceAccountToken ensures that the necessary token is available to the service account. Confirm that this is appropriate for the security model of your deployment.

250-251: Host Network Configuration Explicitly Set to False
The addition of hostNetwork: false clearly indicates the operator will not use the host network, which is good for isolation.

254-293: Expanded Admission Webhooks Configuration
The admissionWebhooks section now includes detailed parameters for cert-manager, CA, and certificate options. The long duration strings and empty commonName for certificates may warrant a review with your security team to ensure they meet operational expectations.

294-307: Service Monitor Configuration Updates
The serviceMonitor section now offers a choice between creating a VMServiceScrape or a ServiceMonitor via the vm flag. The additional settings provide flexibility for users with pre-installed Prometheus Operator CRDs.

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

23-25: Consistent Variable Initialization in RBAC Template
Defining $fullname and $ns using the established $ctx variable helps maintain naming consistency throughout the RBAC roles.

47-50: Determining Watch Namespaces for RBAC
The logic for computing $watchNamespaces, $selfNamespace, and $watchSelfNamespace is clear and improves conditional RBAC role creation for cross-namespace watching.

51-60: ClusterRole Creation Conditioned on Namespace Watch
When the operator is not watching its own namespace exclusively, a ClusterRole is created with nonResourceURLs derived from .Values.allowedMetricsEndpoints. Verify that the formatting with toYaml produces the expected list.

182-192: Cleanup Hook ClusterRole for CRD Resources
The conditional generation of a cleanup ClusterRole (based on CRD creation and cleanup settings) is a well-thought-out addition. Ensure that the cleanup role has the necessary permissions and that its annotations conform to your hook weight policies.

194-218: Aggregated ClusterRoles for Admin and View Permissions
The aggregated ClusterRoles (-victoriametrics-admin and -victoriametrics-view) allow for dynamic inclusion in the default RBAC groups. This makes role management modular.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 200-200: trailing spaces

(trailing-spaces)

packages/system/cilium/charts/cilium/templates/cilium-operator/role.yaml (4)

10-13: Annotations block is correctly templated.
The use of with .Values.operator.annotations and rendering via toYaml keeps the annotations consistent and clean.

14-18: Common labels injection for the ingress secrets role is correct.
The conditional inclusion of .Values.commonLabels with toYaml and nindent 4 is properly applied.

44-46: Consistent commonLabels injection in the gateway secrets role.
The snippet correctly integrates additional labels under the labels key.

72-74: Common labels for the TLS interception secrets role are injected consistently.
The templating is properly indented and follows the same pattern as the other Role resources.

packages/system/cilium/charts/cilium/templates/cilium-agent/service.yaml (2)

17-19: Proper injection of commonLabels in the primary service metadata.
Including common labels here ensures metadata consistency across resources.

49-51: Injection of commonLabels within the alternate service configuration (Envoy metrics branch).
The use of the with directive and proper indentation using nindent 4 is correct.

packages/system/cilium/charts/cilium/templates/hubble/servicemonitor.yaml (3)

1-1: Expanded ServiceMonitor condition.
The revised condition now using (or .Values.hubble.metrics.enabled .Values.hubble.metrics.dynamic.enabled) broadens the criteria to activate the ServiceMonitor. Please verify that this change aligns with the intended monitoring behavior.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

10-12: Common labels injection in ServiceMonitor metadata is consistent.
The block correctly uses with .Values.commonLabels followed by toYaml and nindent 4 to include additional labels.

1-1: Note on YAMLlint error:
A static analysis tool reported a syntax error on line 1. This is likely a false positive caused by Helm templating syntax. Please confirm that the rendered YAML passes proper validation.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/system/cilium/charts/cilium/templates/cilium-agent/rolebinding.yaml (5)

42-44: CommonLabels injection for the cilium-secrets RoleBinding is correctly applied.
The templating and indentation for including .Values.commonLabels ensures label consistency.

68-70: Consistent injection of commonLabels in the cilium-gateway-secrets RoleBinding.
The added lines appropriately extend the labels section with common metadata.

94-96: CommonLabels injection for the cilium-envoy-config-secrets RoleBinding is correct.
The change follows the existing pattern, ensuring consistency across rolebindings.

116-118: Injection of commonLabels in the cilium-bgp-control-plane-secrets RoleBinding.
The labels section is properly extended with the additional common labels.

138-140: Correct inclusion of commonLabels for the cilium-tlsinterception-secrets RoleBinding.
The templated snippet is consistent and maintains the hierarchical metadata structure as expected.

packages/system/cilium/charts/cilium/files/cilium-envoy/configmap/bootstrap-config.yaml (3)

10-10: Ternary operator for listener address configuration is well applied.
The expression {{ .Values.ipv4.enabled | ternary "0.0.0.0" "::" | quote }} correctly selects the appropriate address based on the IPv4 flag.

12-18: Conditional handling for additionalAddresses is correct.
When both IPv4 and IPv6 are enabled, the additional address block is properly added with the IPv6 listener configuration.

299-300: Updated jsonFormat configuration in applicationLogConfig.
Removing the quotes around the expression allows toJson to output a proper JSON structure. Please verify that .Values.envoy.log.format_json produces valid JSON to avoid YAML parsing issues.

packages/system/cilium/charts/cilium/values.schema.json (1)

2121-2126: Review Comment: Policy Restore Timeout Duration

The new "policyRestoreTimeoutDuration" property, which accepts either null or a string, is correctly added to the schema. This flexibility is useful for configuration scenarios where a timeout may be omitted.

Suggestion: If possible, document the expected string format (e.g., ISO 8601 duration or another standard) using a "description" field in the schema to help users configure it correctly.

packages/system/cilium/charts/cilium/templates/cilium-operator/rolebinding.yaml (2)

23-26: Review Subject Declaration Consistency
The subject block for the ingress secrets RoleBinding now shows a list item syntax (i.e. using “- kind: ServiceAccount”) whereas the PR summary mentioned reformatting subjects to remove redundant list syntax. Confirm that this stylistic change is intentional and that all RoleBinding resources follow a uniform structure.

59-66: Validate Namespace Assignment in TLS RoleBinding
In the TLS interception RoleBinding, the metadata uses namespace: {{ .Values.tls.secretsNamespace.name | quote }} while the subject’s namespace is set as {{ .Release.Namespace }}. Please confirm that this difference is deliberate and aligns with your deployment architecture for TLS secret synchronization.

packages/system/cilium/charts/cilium/templates/cilium-agent/daemonset.yaml (2)

235-251: Enhanced Conditional for Metrics Port Exposure
The conditional on line 235 now checks whether either
.Values.prometheus.enabled or one of the hubble metrics flags (.Values.hubble.metrics.enabled or .Values.hubble.metrics.dynamic.enabled) is true before exposing the relevant ports. This improved flexibility should cover both static and dynamic metrics use cases. Please verify that all expected scenarios are handled appropriately.

1002-1040: Refined TLS Setup for Hubble Metrics
The revised block now conditionally projects the hubble-metrics-tls secret when all three conditions are met:

Hubble is enabled,

At least one of the hubble metrics flags is active (static or dynamic), and

TLS for Hubble metrics is enabled.

The fallback logic using the ternary operator for determining whether to use a secret or a configMap for the client CA is a nice touch. Please ensure that this logic is fully tested across different configuration scenarios so that clients consistently receive the correct certificate data.

packages/system/cilium/charts/cilium/values.yaml.tmpl (4)

503-509: Added performance enhancement option with distributed LRU

This addition allows users to enable distributed per-CPU backend memory for BPF LRU maps, which can significantly improve performance. It's disabled by default for compatibility with existing installations.

Note that if you enable this feature, it's recommended to increase BPF map sizing as well to get the full performance benefits.

2361-2365: Added configuration for endpoint policy restoration timeout

This new option allows configuring the maximum time Cilium will wait for endpoint policies to be restored after a restart. The default when not specified is "3m" (3 minutes) as mentioned in the comment.

This provides operators more fine-grained control over the policy restoration process.

2641-2641: Updated TLS secrets documentation

The comment has been updated to clarify that when tls.readSecretsOnlyFromSecretsNamespace is set to false, secrets will be read directly by the agent, improving documentation clarity.

2694-2696: Added tunnel source port range configuration option

This new setting allows configuring the source port range for VXLAN and Geneve tunnels. The default value of "0-0" lets the kernel driver decide the appropriate range.

This provides more flexibility for network configurations where specific source port ranges might be required.

packages/system/cilium/charts/cilium/templates/cilium-configmap.yaml (7)

406-406: Ensure Consistent Integer Casting for BPF Configuration Values
These changes explicitly cast various BPF configuration values to integers (e.g.
• bpf-auth-map-max at line 406
• bpf-ct-global-tcp-max at line 422
• bpf-ct-global-any-max at line 425
• bpf-conntrack-accounting at line 429
• bpf-nat-global-max at line 434
• bpf-neigh-global-max at line 439
• bpf-policy-map-max at line 444
• bpf-lb-map-max at line 449)
This promotes type safety and ensures that downstream consumers receive numeric values as expected. Please verify that incoming values in .Values are indeed appropriate for integer conversion.

Also applies to: 422-422, 425-425, 429-429, 434-434, 439-439, 444-444, 449-449

464-464: Verify Boolean Flag Quoting for BPF Distributed LRU
The configuration for bpf-distributed-lru (line 464) is now explicitly quoted. Confirm that the value provided (likely a boolean represented as a string) matches the expected input for Cilium’s configuration downstream.

517-519: New Tunnel Source Port Range Configuration
A new conditional block for tunnel-source-port-range has been added (lines 517–519). This inclusion ensures that if a value is provided in .Values.tunnelSourcePortRange, it is properly output into the config with quoting. Verify that this new field integrates correctly with the underlying service and that its data type (string, after quoting) is acceptable.

947-957: Hubble Metrics Server Configuration Enhancements
Within the Hubble configuration block, a new section is conditionally inserted when either static or dynamic Hubble metrics are enabled (lines 947–957). This section configures the metrics server address (with the port prefixed by a colon), TLS settings (including certificate and key file paths), and optionally client CA files if mTLS is enabled. Please verify that the port formatting (e.g. ":{{ .Values.hubble.metrics.port }}") and file paths match your deployment’s requirements and that they do not introduce any unintended formatting issues.

964-966: Iterating over Hubble Metrics List
The template now iterates over .Values.hubble.metrics.enabled to produce the hubble-metrics list (lines 964–966). Confirm that the output format (with each metric on a new indented line) is correctly parsed by downstream consumers. If a space-separated or comma-separated list is required instead, consider adjusting the formatting accordingly.

967-969: Dynamic Metrics Configuration Path Added for Hubble
A new conditional block (lines 967–969) adds the configuration key hubble-dynamic-metrics-config-path when dynamic Hubble metrics are enabled. It hardcodes the file path to /dynamic-metrics-config/dynamic-metrics.yaml. Please ensure that this file exists at runtime and that Cilium’s Hubble component is configured to read dynamic metrics from this location.

1049-1051: IPAM Multi-Pool Pre-Allocation Configuration
A conditional block has been introduced at lines 1049–1051 which adds the ipam-multi-pool-pre-allocation setting when defined in .Values.ipam.multiPoolPreAllocation. Confirm that the value (properly quoted) is in the expected format and that the IPAM operator correctly understands and applies this configuration.

packages/system/cilium/charts/cilium/README.md (8)

3-3: Updated Version Badge:
The version badge on line 3 now shows “1.17.2”. This update looks correct and helps ensure consistency with the updated Chart version. Please verify that all related version references (e.g. in Chart.yaml and elsewhere) are updated accordingly.

88-88: Verify SPIRE Init Image Update:
The configuration for authentication.mutual.spire.install.initImage on line 88 now uses a new digest and tag (busybox image tagged “1.37.0”). Please ensure that this update is intentional, the image is secure, and compatible with the SPIRE integration components.

200-200: Updated Clustermesh API Server Image:
The image for clustermesh.apiserver.image on line 200 is now updated to tag “v1.17.2” with a new digest. Please verify that the new image is functionally equivalent and compatible with the rest of the deployment.

397-397: Policy Restore Timeout Adjustment:
The envoy.policyRestoreTimeoutDuration on line 397 is now set to nil (defaulting effectively to a “3m” behavior as noted in the description). Ensure that this change does not adversely affect policy reloading or introduce unexpected delays.

521-521: Hubble Relay Image Update:
The hubble-relay image on line 521 has been updated to tag “v1.17.2” with the new digest. Please confirm that this image has been tested in your monitoring stack and that it fixes the relevant dependency issues.

588-588: Hubble UI Backend Image Updated:
The hubble-ui backend image on line 588 has been updated to tag “v0.13.2”. Ensure that this update is in line with the overall release strategy and that any dependent UI functionality or integrations are verified.

598-598: Hubble UI Frontend Image Updated:
The hubble-ui frontend image on line 598 is now updated to tag “v0.13.2”. As this works in tandem with the backend changes, please test that the frontend renders correctly and communicates with its backend counterparts.

628-628: Agent Container Image Update:
The main agent container image on line 628 has been updated to tag “v1.17.2” with a new digest. Please ensure that this update has been validated with other dependent components and that upgrading will not break compatibility across the system.

packages/system/cilium/charts/cilium/values.yaml (15)

192-198: Cilium Agent Image Update:
The image settings for the cilium-agent have been updated with tag "v1.17.2" and a new digest value. The override field is unset (indicated by ~), which is appropriate if no custom override is needed. Please verify that this upgrade aligns with the requirements of your deployment.

2341-2345: New Policy Restore Timeout Option:
A new configuration, policyRestoreTimeoutDuration, has been added (with a default of null) to define the maximum duration to wait for endpoint policies to be restored on restart. Ensure that having a null default is intentional and that downstream logic handles this configuration as expected.

2352-2357: Cilium Envoy Image Update:
The Envoy container image has been updated with the new tag "v1.31.5-1741765102-efed3defcc70ab5b263a0fc44c93d316b846a211" and an updated digest. Confirm that this new version is compatible with your system's expectations and any related integrations.

2673-2675: Tunnel Source Port Range Configuration:
The new tunnelSourcePortRange parameter has been introduced with a default value of "0-0", which delegates the source port selection to the kernel driver. Please ensure that this setting meets your networking and tunneling requirements.

2910-2915: Cilium NodeInit Image Update:
The node-init image configuration has been updated (repository "quay.io/cilium/startup-script", tag "c54c7edeab7fde4da68e59acd319ab24af242c3f", and a new digest). This change should be validated to ensure that the node initialization process functions correctly with the new image.

2991-2996: Preflight Image Update:
The preflight image has been updated with tag "v1.17.2" and its corresponding digest. Ensure that this update does not adversely affect upgrade procedures and that the preflight checks remain reliable post-upgrade.

3141-3147: Clustermesh API Server Image Update:
The clustermesh-apiserver image has been updated to tag "v1.17.2" with an updated digest. This update is key for proper operation of ClusterMesh; please confirm that the revised image integrates smoothly with your multi-cluster configuration.

3649-3654: SPIRE Init Image Update:
Within the SPIRE section, the init container image (using BusyBox) now has an updated digest. Verify that this change does not impact the SPIRE initialization process or its interaction with other SPIRE components.

3664-3669: SPIRE Agent Image Update:
The SPIRE agent image has been updated to version "1.9.6" with a new digest. This update should be tested to ensure that the SPIRE agent continues to integrate properly with the SPIRE server and that mutual authentication remains secure.

3718-3723: SPIRE Server Image Update:
The SPIRE server image configuration has been updated to version "1.9.6" with a corresponding new digest. Given the critical nature of SPIRE components in security, please ensure that these changes are validated in your environment.

2708-2721: Cilium Operator Image Update:
The cilium-operator image has been updated with tag "v1.17.2" and new digest values (including specific digests for generic, Azure, AWS, and AlibabaCloud deployments). Please verify that these image updates have been tested across the respective platforms and that they meet the deployment requirements.

1690-1695: Hubble UI Backend Image Update:
The Hubble UI backend image has been updated to tag "v0.13.2" with a new digest. Ensure that the backend service components for Hubble UI operate as expected with this image revision.

1726-1731: Hubble UI Frontend Image Update:
The Hubble UI frontend image now uses tag "v0.13.2" with an updated digest. Please verify that the frontend interface remains fully functional and that the upgrade is consistent with the backend updates.

3664-3669:

3718-3723:

packages/system/keycloak-operator/charts/keycloak-operator/Chart.yaml (3)

275-281: Version and Image Update
The container image and version have been updated from 1.23.0 to 1.25.0. The new image tag and version fields (including the trailing slash in the documentation URL) are consistent with the intended release. Please verify that the new image is available in the registry and that all dependent charts or documentation refer to the updated version consistently.

286-286: Application Version Update
The field “appVersion: 1.25.0” now correctly reflects the new release.

311-311: Chart Version Field Updated
The chart’s version field has been bumped to 1.25.0. Ensure that any related dependency/version mapping in other charts is updated accordingly.

packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_keycloakrealms.yaml (1)

26-33: Additional Printer Columns in CRD
Two new additional printer columns – “Realm” and “Keycloak” – have been added to enhance the output when listing KeycloakRealms. The columns use a boolean type but are derived from the .spec.realmName and .spec.keycloakRef fields. Please double-check that the boolean type is the intended representation and that the data coming from these fields is appropriately cast.

packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_keycloakclients.yaml (3)

47-55: New Client Admin Configuration Fields
Two new fields have been added:
• adminFineGrainedPermissionsEnabled – to toggle fine-grained admin permission behavior.
• adminUrl – which specifies a client admin URL (with a fallback to webUrl).
These additions improve control over client behavior. Please confirm that any client components relying on these values have been adjusted accordingly.

457-458: Addition of homeUrl Field
The new homeUrl property in the client spec offers a dedicated field for the client’s home URL. This should be clearly documented in your client user guide and ensures that front-end routing uses the correct address.

473-492: New Permission Mapping for Clients
A new permission object has been added with a nested scopePermissions array, framing a mapping between a permission name and the list of policies associated with that scope. This change enhances the granularity of authorization settings. Please ensure that:
• The operator’s reconciliation logic validates the existence of the specified policies.
• The schema examples are updated to reflect real-world usage scenarios.

packages/system/keycloak-operator/charts/keycloak-operator/crds/v1.edp.epam.com_clusterkeycloakrealms.yaml (1)

22-29: Additional Printer Columns for ClusterKeycloakRealms
New printer columns – “Realm” (derived from .spec.realmName) and “Cluster-Keycloak” (derived from .spec.clusterKeycloakRef) – have been added for cluster-scoped realms. Ensure that the boolean data types for these columns meet your expectations; if these fields are strings in practice, you may want to adjust the types.

packages/system/keycloak-operator/charts/keycloak-operator/_crd_examples/keycloakrealm.yaml (1)

35-79: Enhanced User Profile Configuration

The new userProfileConfig block introduces detailed configuration for user attributes and groups, thus extending the KeycloakRealm’s customization capabilities. Please verify that these fields (such as unmanagedAttributePolicy, attributes, and groups) conform to the CRD schema and that the associated validations and annotations meet business requirements.

packages/system/keycloak-operator/charts/keycloak-operator/_crd_examples/keycloakclient.yaml (4)

15-16: Addition of Admin and Home URLs

The first KeycloakClient now includes new adminUrl and homeUrl fields. These additions improve the client's routing and administrative accessibility. Confirm that the URLs provided match downstream integration requirements.

28-35: Updated Client Identifier and Secret

In the second KeycloakClient definition, key fields have been updated:

metadata.name has changed to keycloakclient-authorization-sample.

clientId is now set to authorization-sample.

The secret reference has been updated accordingly.
Ensure that all dependent configurations and secret management routines reflect these changes.

41-49: Enhanced Authorization Block

The authorization section now explicitly defines both scopes and a detailed resources configuration. This granularity should help enforce precise access control policies. Verify that these new settings integrate smoothly with existing authorization mechanisms and that the schema requirements for Keycloak authorization are met.

126-128: Secret Naming Consistency

The Secret’s metadata has been updated to client-secret-authorization-sample to align with the changes in the KeycloakClient specification. Please double-check that all references to the secret are updated across the deployment to maintain consistency and security.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_image.tpl (3)

5-15: Validate and assemble base image string
Enforcing a fail if .repository is missing ensures correct usage. Attaching the registry when present is a logical and clean approach.

17-36: Dynamically determine image tag
Graceful fallback to the chart’s .AppVersion and optional “enterprise” variant logic is well-structured, allowing flexible configuration for different deployments.

38-60: Flexible resolution of $image through appKey
This segment elegantly merges local context with global values, with early failure if data is missing. The fallback for .registry from global settings improves maintainability.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_service.tpl (3)

5-11: Fail on invalid .style argument
Initializing $nameTpl to "" and raising a clear error for unsupported values prevents misconfiguration and improves user feedback.

37-56: Consolidate host data from $values and $ctx
Iterating appKey to merge relevant fields and set port demonstrates a robust approach for Helm-based customization. No concerns on the fallback logic.

69-87: Refined URL construction with conditional HTTPS
Dynamically computing protocol and trimming trailing slashes supports multiple scenarios cleanly. The approach is clear and consistent with vm.host.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_helpers.tpl (8)

10-13: Enforce minimum Helm version requirement.

A new validation has been added that requires Helm 3.14.0 or higher. This is a reasonable check to ensure compatibility, but it would be helpful to understand if there are specific features in Helm 3.14.0 that this chart requires.

24-29: Good addition of name truncation control.

The implementation of disableNameTruncation provides flexibility while respecting Kubernetes naming conventions (63 character limit) by default. This approach maintains backward compatibility while adding a useful new feature.

43-60: Enhanced fullname logic with improved override precedence.

The refactored fullname override logic now has a clearer hierarchy (local override > global override > generated name) and supports templating with the tpl function. This is a good improvement that enhances both functionality and readability.

63-77: New template for custom resource naming.

The new vm.cr.fullname template follows a consistent pattern with other naming functions while providing specific functionality for custom resources. The implementation is clean and follows the established patterns for name generation and truncation.

118-144: Robust key resolution helper implementation.

The new vm.internal.key helper provides sophisticated key resolution from nested structures with proper error handling and fallback mechanisms. While somewhat complex, this implementation enables more flexible and reliable name generation throughout the templates.

186-193: Dedicated template for pod labels.

The new vm.podLabels template provides specific label generation for pods, ensuring selector labels are included while allowing for customization through extraLabels. This is a good addition that enhances label management capabilities.

200-202: Improved version extraction for labels.

This enhancement extracts version information from image tags while properly handling SHA digests, ensuring that app.kubernetes.io/version is set correctly. This follows Kubernetes labeling best practices.

232-236: Style-based component labeling.

The addition of style-based labeling (managed vs default) provides flexibility in how components are labeled, which is important for integrating with different tools and workflows that may have specific labeling expectations.

packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_enterprise.tpl (2)

3-9: Improved license secret key handling with clearer precedence

The refactoring introduces separate variables for plain and managed license keys, with explicit precedence. This improves readability and maintainability by breaking down complex nested expressions.

14-20: Consistent approach to license secret name handling

This change mirrors the pattern used for license secret keys, creating a consistent approach throughout the template. This is good practice that makes the code more maintainable.

coderabbitai · 2025-04-03T16:56:36Z

  {{- $licenseSecretKey := (include "vm.license.secret.key" .) -}}
  {{- $licenseSecretName := (include "vm.license.secret.name" .) -}}
-  {{- and (empty $licenseKey) (and (empty $licenseSecretName) (empty $licenseSecretKey)) -}}
+  {{- or .noEnterprise (and (empty $licenseKey) (and (empty $licenseSecretName) (empty $licenseSecretKey))) -}}


💡 Verification agent

🧩 Analysis chain

Enhanced enterprise disabling logic

Adding the .noEnterprise condition provides an explicit way to disable enterprise features regardless of license configuration, improving flexibility.

🏁 Script executed:

#!/bin/bash # Check where the .noEnterprise variable is used or set in the codebase echo "Checking for noEnterprise usage in Helm templates:" rg --type yaml -l "\.noEnterprise" --glob "*.yaml" --glob "*.tpl" --glob "*.yml" echo -e "\nChecking for documentation of this parameter:" rg --type yaml "noEnterprise" --glob "values.yaml" --glob "README*"

Length of output: 498

Verify and Document the 'noEnterprise' Parameter Usage

The updated template in
packages/system/victoria-metrics-operator/charts/victoria-metrics-operator/charts/victoria-metrics-common/templates/_enterprise.tpl
correctly integrates the .noEnterprise flag to explicitly disable enterprise features, enhancing configuration flexibility.

Verification confirms that the parameter is used as intended in the template.

However, a search in values.yaml and any README files did not reveal any documentation for .noEnterprise. It is recommended to add proper documentation to help users understand its purpose and usage.

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Andrei Kvapil (kvaps) · 2025-04-10T12:40:26Z

Closed in favor:

Andrei Kvapil (kvaps) requested a review from Timofei Larkin (lllamnyp) as a code owner April 3, 2025 14:55

Andrei Kvapil (kvaps) added the ok-to-test Indicates a non-member PR is safe to run CI on label Apr 3, 2025

coderabbitai Bot reviewed Apr 3, 2025

View reviewed changes

Andrei Kvapil (kvaps) force-pushed the fix-tests branch from 0241e56 to 5078331 Compare April 3, 2025 15:24

Andrei Kvapil (kvaps) changed the title ~~[tests] Fix timeouts for awaiting tenant-root applications~~ [tests] Fix dependency for monitoring Apr 3, 2025

Andrei Kvapil (kvaps) force-pushed the fix-tests branch 2 times, most recently from b5b974f to 4e36502 Compare April 3, 2025 16:39

Andrei Kvapil (kvaps) changed the title ~~[tests] Fix dependency for monitoring~~ [tests] Fix test Apr 3, 2025

Andrei Kvapil (kvaps) marked this pull request as draft April 3, 2025 16:40

coderabbitai Bot reviewed Apr 3, 2025

View reviewed changes

klinch0 added ok-to-test Indicates a non-member PR is safe to run CI on and removed ok-to-test Indicates a non-member PR is safe to run CI on labels Apr 7, 2025

klinch0 force-pushed the fix-tests branch 6 times, most recently from fe7862d to 91d752f Compare April 9, 2025 21:51

Andrei Kvapil (kvaps) and others added 8 commits April 10, 2025 11:58

[tests] Fix e2e tests (dependencies and timeouts)

ae61995

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Upd: victoria-metrics operator to v0.55.0

ddb2377

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Update Cluster-API operator to v0.18.1

2393e34

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Upd: Keycloak-operator to v1.25.0

e8faf19

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Upd: Kamaji to v0.9.2

ad8e09b

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Upd: Cilium to v1.17.2

6afb1aa

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>

Upd: Kube-OVN to v1.13.6

1234872

fix

5baa480

klinch0 force-pushed the fix-tests branch from 91d752f to 5baa480 Compare April 10, 2025 08:58

fix image tag for victorialogs

db7c591

klinch0 force-pushed the fix-tests branch from b4e8794 to db7c591 Compare April 10, 2025 11:04

fix updateStatus field

39b31ca

Timofei Larkin (lllamnyp) approved these changes Apr 10, 2025

View reviewed changes

Andrei Kvapil (kvaps) closed this Apr 10, 2025

Navigation Menu

Uh oh!

[tests] Fix test - #753

[tests] Fix test#753
Andrei Kvapil (kvaps) wants to merge 10 commits into
mainfrom
fix-tests

Andrei Kvapil (kvaps) commented Apr 3, 2025 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Apr 3, 2025 •

edited

Loading

Review skipped

Chat

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (`.coderabbit.yaml`)

Documentation and Community

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot Apr 3, 2025

Uh oh!

Andrei Kvapil (kvaps) commented Apr 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Andrei Kvapil (kvaps) commented Apr 3, 2025 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Walkthrough

Changes

Sequence Diagram(s)

Poem

Chat

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Apr 3, 2025

Choose a reason for hiding this comment

Uh oh!

Andrei Kvapil (kvaps) commented Apr 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Andrei Kvapil (kvaps) commented Apr 3, 2025 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Apr 3, 2025 •

edited

Loading

CodeRabbit Configuration File (`.coderabbit.yaml`)