feature/add-vpa-for-monitoring - #676
Conversation
WalkthroughThe changes introduce a comprehensive update to the vertical pod autoscaler deployment. New release configurations were added in existing YAML bundles for both full and hosted platforms, and supporting monitoring package versions were bumped. In addition, an entirely new Helm chart for the vertical pod autoscaler was created. This chart encompasses numerous templated files for common Helm functions (labels, affinities, secrets, validations, etc.) as well as distinct components for the admission-controller, CRDs, recommender, updater, and testing. New default configuration values and resource limits have also been defined. Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant HC as Helm Client
participant TE as Templating Engine
participant K8s as Kubernetes API
participant AC as Admission Controller
participant RC as Recommender
participant UP as Updater
participant CRD as Custom Resource Definitions
U->>HC: Execute helm install/update
HC->>TE: Render chart templates (helpers, validations, etc.)
TE-->>HC: Rendered Kubernetes manifests
HC->>K8s: Apply manifests to cluster
K8s->>CRD: Create/Update CRDs (VPA, Checkpoints)
K8s->>AC: Deploy admission controller components
K8s->>RC: Deploy recommender component
K8s->>UP: Deploy updater component
sequenceDiagram
participant Helm as Helm Chart
participant Templates as Chart Templates
participant Resources as Kubernetes Resources
Helm->>Templates: Process helper & validation templates
Templates->>Resources: Generate manifests for admission / recommender / updater, etc.
Resources-->>Helm: Confirm resource readiness (via probes/setup)
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Nitpick comments (32)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml (1)
1-4: Implementation for extra deployments looks goodThe template correctly implements a mechanism to render additional custom resources specified in
.Values.extraDeploy. This approach provides flexibility for extending the vertical pod autoscaler deployment with custom configurations.You might consider adding a conditional check to skip this section entirely when
.Values.extraDeployis empty or not defined, though this isn't strictly necessary as the range loop will not execute when empty.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml (1)
4-13: Metadata Configuration and Indentation Verification
The metadata section effectively uses templating to populate the resource name, labels, and annotations. Note that YAMLlint reports indentation warnings on lines 9–10. Please render the template withhelm templateto ensure that the final YAML output is correctly indented.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml (1)
9-15: Labels Section and Indentation Concerns
The labels are assembled from component-specific as well as common values. YAMLlint warnings regarding indentation (notably on lines 11–15) are likely false positives due to the use of thenindentfunction. It’s recommended to verify the rendered output viahelm template.🧰 Tools
🪛 YAMLlint (1.35.1)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml (1)
4-10: Metadata and Label Definitions
The metadata block dynamically generates the ServiceAccount name and labels. Although YAMLlint issues warnings on lines 9–10 regarding indentation, this is typically a false positive owing to templating. It is advisable to validate the final YAML throughhelm template.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md (1)
1-235: Comprehensive documentation with a few minor grammatical issues.The README provides thorough documentation of the common library chart, its usage, and configuration options. It will be valuable for users implementing the vertical-pod-autoscaler.
Consider these minor grammatical improvements:
- Line 31: Change "provides a common template helpers" to "provides common template helpers"
- Line 140: Change "some times" to "sometimes"
- Line 207: Change "has been ordered" to "have been ordered" to match the plural subject "fields"
🧰 Tools
🪛 LanguageTool
[uncategorized] ~31-~31: Possible missing comma found.
Context: ... This chart provides a common template helpers which can be used to develop new charts...(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~140-~140: Did you mean the adverb “sometimes” (= occasionally)?
Context: ...tive data for a deployment in a secret, some times we want to give to users the possibilit...(SOME_TIMES)
[uncategorized] ~184-~184: A comma might be missing here.
Context: ... }}If we force those values to be empty we will see some alertsconsole hel...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
[uncategorized] ~205-~205: This verb may not be in the correct tense. Consider changing the tense to fit the context better.
Context: ... - Previous versions of this Helm Chart useapiVersion: v1(installable by both H...(AI_EN_LECTOR_REPLACEMENT_VERB_TENSE)
[uncategorized] ~207-~207: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...fields present in the Chart.yaml file has been ordered alphabetically in a homoge...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[style] ~212-~212: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... you shouldn't face any issues - If you want to upgrade to this version using Helm v2, ...(REP_WANT_TO_VB)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml (2)
16-50: Test suite for connectivity verification looks robust.The Python test script covers all key components of the vertical-pod-autoscaler. However, there's no error handling in the test functions, which could make diagnosing failures difficult.
Consider adding try/except blocks to provide more informative error messages when tests fail:
def test_admission_controller_service_connection(): url = "https://vpa-webhook.{{ .Release.Namespace }}.svc:{{ .Values.admissionController.service.ports.https }}/" verify = "/admission-controller-tls-secret/ca.crt" - response = requests.get(url, verify=verify) - - assert response.status_code == 200 + try: + response = requests.get(url, verify=verify) + assert response.status_code == 200 + except requests.RequestException as e: + assert False, f"Failed to connect to admission controller: {e}" + except AssertionError: + assert False, f"Unexpected status code: {response.status_code}"Similar improvements could be made to the other test functions.
22-26: Consider adding timeout parameter to requests.The requests to service endpoints don't specify a timeout, which could cause tests to hang indefinitely if a service is unresponsive.
- response = requests.get(url, verify=verify) + response = requests.get(url, verify=verify, timeout=10)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md (3)
7-7: Remove Trailing Punctuation in HeadingThe heading "## TL;DR;" includes an unnecessary semicolon. Please remove it for proper Markdown style.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
7-7: Trailing punctuation in heading
Punctuation: ';'(MD026, no-trailing-punctuation)
43-43: Refine Superlative WordingThe phrase "with the most latest release" should be simplified to "with the latest release" for correct grammar.
🧰 Tools
🪛 LanguageTool
[grammar] ~43-~43: Only “latest” (without ‘most’) is used to write the superlative.
Context: ...istingmy-releasedeployment with the most latest release of the chart. TIP: Use `he...(MOST_SUPERLATIVE)
53-53: Improve Clarity in Service Injection DescriptionThe sentence "Information about services are no more injected into pod's environment variable." can be rephrased for clarity. Consider something like:
"Service information is no longer injected into pods' environment variables."🧰 Tools
🪛 LanguageTool
[uncategorized] ~53-~53: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...caler-1.3.0 Information about services are no more injected into pod's environment...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~53-~53: You might be missing the article “the” here.
Context: ...bout services are no more injected into pod's environment variable. ### Upgrading ...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
packages/system/vertical-pod-autoscaler/values.yaml (2)
1-8: Consider different memory requests and limits for the updater componentThe memory requests and limits are set to the same value (1100Mi). While this ensures consistent memory allocation, it might be more efficient to set requests lower than limits to allow for better resource utilization.
updater: resources: limits: memory: 1100Mi requests: cpu: 200m - memory: 1100Mi + memory: 900Mi
15-21: Consider different memory requests and limits for the recommender componentSimilar to the updater component, the memory requests and limits are identical (1600Mi). Consider setting requests lower than limits for more efficient resource utilization.
recommender: resources: limits: memory: 1600Mi requests: cpu: 100m - memory: 1600Mi + memory: 1200Mipackages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml (1)
1-10: Service configuration is well-structured but has minor indentation issuesThe service for the admission controller has a good structure with flexible configuration options. However, there are minor indentation issues in the labels section.
Fix the indentation in the labels section:
metadata: name: vpa-webhook labels: {{- include "vertical-pod-autoscaler.admissionController.labels" . | nindent 4 }} {{- if .Values.commonLabels }} - {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} - {{- end }} + {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} + {{- end }}🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml (1)
82-118: Health checks are comprehensive but consider adding a configurable path.The probes configuration is thorough with configurable timing parameters. All three probe types (liveness, readiness, startup) use the same
/health-checkendpoint.Consider making the health check path configurable in values.yaml rather than hardcoding it, which would provide more flexibility:
livenessProbe: httpGet: - path: /health-check + path: {{ .Values.recommender.livenessProbe.path | default "/health-check" }} port: http-metricspackages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml (2)
86-90: Minor typo in description field.There's a typo in the description field for
firstSampleStart- "Timestamp of the fist sample" should be "Timestamp of the first sample".firstSampleStart: - description: Timestamp of the fist sample from the histograms. + description: Timestamp of the first sample from the histograms. format: date-time nullable: true type: string
186-190: Same typo appears in v1beta2 schema.The same typo appears in the v1beta2 schema section and should be corrected for consistency.
firstSampleStart: - description: Timestamp of the fist sample from the histograms. + description: Timestamp of the first sample from the histograms. format: date-time nullable: true type: stringpackages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml (1)
35-50: Consider future API version changes for VPA resourcesThe ClusterRole includes permissions for both
poc.autoscaling.k8s.ioandautoscaling.k8s.ioAPI groups for verticalpodautoscalers. This is good for backward compatibility, but consider adding a comment explaining why both are needed and when the legacypocgroup might be removed.# system:vpa-actor - apiGroups: - "poc.autoscaling.k8s.io" resources: - verticalpodautoscalers verbs: - get - list - watch + # Both API groups are included for backwards compatibility + # The "poc.autoscaling.k8s.io" is the legacy API group that might be deprecated in future - apiGroups: - "autoscaling.k8s.io" resources: - verticalpodautoscalers verbs: - get - list - watchpackages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml (1)
11-14: Consider adding documentation for the annotation merging logic.The annotation merging approach using
common.tplvalues.mergeis powerful but might benefit from a comment explaining the merge priority (which annotations would override others in case of conflicts).packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml (2)
5-9: Fix indentation consistency in labels and annotationsThe indentation in the labels and annotations sections uses 4 spaces where the rest of the file uses 2 spaces.
name: verticalpodautoscalers.autoscaling.k8s.io labels: - {{- include "vertical-pod-autoscaler.labels" . | nindent 4 }} - {{- if .Values.commonLabels }} - {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} + {{- include "vertical-pod-autoscaler.labels" . | nindent 2 }} + {{- if .Values.commonLabels }} + {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 2 }}🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
13-15: Fix indentation in annotations sectionSimilar to the labels section, the annotations section uses inconsistent indentation.
annotations: api-approved.kubernetes.io: https://github.com/kubernetes/kubernetes/pull/63797 controller-gen.kubebuilder.io/version: v0.16.5 {{- if .Values.commonAnnotations }} - {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 4 }} + {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 2 }}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_redis.tpl (2)
17-39: Validation function looks complete but missing error handling for empty existingSecretValueThe validation function correctly checks for Redis password requirements when authentication is enabled. It properly handles the case when existingSecret is not provided, but doesn't validate if the existingSecretValue itself is empty when provided.
Consider adding a check for empty existingSecretValue. When existingSecret is provided but is empty, the validation should still occur:
{{- if and (or (not $existingSecret) (eq $existingSecret "\"\"")) (eq $enabled "true") -}} + {{- /* Existing code */ -}} + {{- else if and (not (empty $existingSecretValue)) (eq $existingSecretValue "\"\"") (eq $enabled "true") -}} + {{- /* Same validation as above */ -}} {{- end -}}
73-81: Function could use defensive coding against nil valuesThe function might encounter issues if either
$standarizedAuthor$standarizedAuthValuesis nil or has unexpected formatting.Consider adding defensive code to handle nil values and improve error handling:
{{- define "common.redis.values.standarized.version" -}} {{- $standarizedAuth := printf "%s%s" (include "common.redis.values.keys.prefix" .) "auth" -}} {{- $standarizedAuthValues := include "common.utils.getValueFromKey" (dict "key" $standarizedAuth "context" .context) }} + {{- if and $standarizedAuth $standarizedAuthValues -}} - {{- if $standarizedAuthValues -}} {{- true -}} + {{- else -}} + {{- false -}} {{- end -}} {{- end -}}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_warnings.tpl (3)
14-17: Rolling tag warning should include a clearer action itemThe warning message correctly identifies when a rolling tag is detected but could be more explicit about the recommended action.
Consider enhancing the warning message with a clearer action item:
-WARNING: Rolling tag detected ({{ .repository }}:{{ .tag }}), please note that it is strongly recommended to avoid using rolling tags in a production environment. +WARNING: Rolling tag detected ({{ .repository }}:{{ .tag }}). It is strongly recommended to use immutable tags in production environments. Please update to a specific version tag to ensure stability. +info https://docs.vmware.com/en/VMware-Tanzu-Application-Catalog/services/tutorials/GUID-understand-rolling-tags-containers-index.html
25-45: Improve modified images warning with more specific security contextThe warning about substituted images effectively detects changes but could be more specific about security implications.
Consider enhancing the warning with more specific security context:
-⚠ SECURITY WARNING: Original containers have been substituted. This Helm chart was designed, tested, and validated on multiple platforms using a specific set of Bitnami and Tanzu Application Catalog containers. Substituting other containers is likely to cause degraded security and performance, broken chart features, and missing environment variables. +⚠ SECURITY WARNING: Original containers have been substituted. This Helm chart was designed, tested, and validated using specific Bitnami and Tanzu Application Catalog containers. Using substituted containers may introduce: + - Security vulnerabilities due to missing security patches and hardening + - Performance degradation from sub-optimal configurations + - Broken chart features due to missing expected files or configurations + - Runtime errors from missing environment variables
59-109: Resources warning function has high complexity and could be simplifiedThe function for checking resources is well-implemented but has high complexity with multiple nested conditionals. It correctly handles different scenarios but could be simplified for better maintainability.
Consider refactoring this function to reduce nesting levels, perhaps by extracting sublogic into helper functions:
{{- define "common.warnings.resources" -}} {{- $values := .context.Values -}} {{- $printMessage := false -}} {{ $affectedSections := list -}} + {{/* Helper function to check if a section should be included based on enabled/replicaCount */}} + {{- define "shouldIncludeSection" -}} + {{- $section := .section -}} + {{- if and (hasKey $section "enabled") -}} + {{- if index $section "enabled" -}}true{{- end -}} + {{- else if and (hasKey $section "replicaCount") -}} + {{- if (gt (index $section "replicaCount" | int) 0) -}}true{{- end -}} + {{- else -}}true{{- end -}} + {{- end -}} + {{- range .sections -}} {{/* Continue with simplified logic using the helper function */}} {{- end -}} {{- end -}}This is a conceptual suggestion - implementing a helper function within templates has specific syntax requirements.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mariadb.tpl (3)
16-46: MariaDB password validation function looks robust but could be simplifiedThe MariaDB password validation is thorough, but the structure with multiple variable assignments before the main conditional could be simplified for better readability.
Consider moving some variable assignments inside the main conditional block for clarity:
{{- define "common.validations.values.mariadb.passwords" -}} {{- $existingSecret := include "common.mariadb.values.auth.existingSecret" . -}} {{- $enabled := include "common.mariadb.values.enabled" . -}} - {{- $architecture := include "common.mariadb.values.architecture" . -}} - {{- $authPrefix := include "common.mariadb.values.key.auth" . -}} - {{- $valueKeyRootPassword := printf "%s.rootPassword" $authPrefix -}} - {{- $valueKeyUsername := printf "%s.username" $authPrefix -}} - {{- $valueKeyPassword := printf "%s.password" $authPrefix -}} - {{- $valueKeyReplicationPassword := printf "%s.replicationPassword" $authPrefix -}} {{- if and (or (not $existingSecret) (eq $existingSecret "\"\"")) (eq $enabled "true") -}} + {{- $architecture := include "common.mariadb.values.architecture" . -}} + {{- $authPrefix := include "common.mariadb.values.key.auth" . -}} + {{- $valueKeyRootPassword := printf "%s.rootPassword" $authPrefix -}} + {{- $valueKeyUsername := printf "%s.username" $authPrefix -}} + {{- $valueKeyPassword := printf "%s.password" $authPrefix -}} + {{- $valueKeyReplicationPassword := printf "%s.replicationPassword" $authPrefix -}} {{- $requiredPasswords := list -}} {{/* Rest of the implementation */}}This approach only calculates values when they're needed, potentially improving template rendering performance.
56-62: Function has inconsistent return value handling compared to other similar functionsUnlike some other functions in these templates, the
common.mariadb.values.auth.existingSecretfunction returns quoted values but doesn't provide a default when values don't exist.Consider adding default value handling for consistency:
{{- define "common.mariadb.values.auth.existingSecret" -}} {{- if .subchart -}} - {{- .context.Values.mariadb.auth.existingSecret | quote -}} + {{- default "" .context.Values.mariadb.auth.existingSecret | quote -}} {{- else -}} - {{- .context.Values.auth.existingSecret | quote -}} + {{- default "" .context.Values.auth.existingSecret | quote -}} {{- end -}} {{- end -}}
102-108: Function name in this template doesn't match other templates' naming conventionThe function
common.mariadb.values.key.authfollows a different naming convention compared to other functions likecommon.redis.values.keys.prefix.For consistency across the codebase, consider renaming the function to match the naming convention of other similar functions:
-{{- define "common.mariadb.values.key.auth" -}} +{{- define "common.mariadb.values.keys.auth" -}}Don't forget to update all references to this function throughout the code.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_secrets.tpl (3)
20-38: Secret name generator could use a helper function for type checkingThe function correctly handles both string and object types for existingSecret, but the logic could be extracted to a helper function for better reuse.
Consider extracting the type checking logic to a helper function that could be used by other methods in this file:
+{{/* +Helper function to get the name from an existingSecret object or string +*/}} +{{- define "common.secrets.getNameFromExistingSecret" -}} + {{- $name := "" -}} + {{- with . -}} + {{- if not (typeIs "string" .) -}} + {{- with .name -}} + {{- $name = . -}} + {{- end -}} + {{- else -}} + {{- $name = . -}} + {{- end -}} + {{- end -}} + {{- printf "%s" $name -}} +{{- end -}} {{- define "common.secrets.name" -}} {{- $name := (include "common.names.fullname" .context) -}} {{- if .defaultNameSuffix -}} {{- $name = printf "%s-%s" $name .defaultNameSuffix | trunc 63 | trimSuffix "-" -}} {{- end -}} - {{- with .existingSecret -}} - {{- if not (typeIs "string" .) -}} - {{- with .name -}} - {{- $name = . -}} - {{- end -}} - {{- else -}} - {{- $name = . -}} - {{- end -}} - {{- end -}} + {{- $secretName := include "common.secrets.getNameFromExistingSecret" .existingSecret -}} + {{- if $secretName -}} + {{- $name = $secretName -}} + {{- end -}} {{- printf "%s" $name -}} {{- end -}}
92-142: Password management function has high complexityThe password management function is comprehensive but has high complexity with multiple conditions and branches. It properly handles different scenarios for password retrieval or generation.
Consider breaking this function into smaller, more focused subfunctions:
- A function to retrieve password from existing secret
- A function to get password from provided values
- A function to generate new password
This would make the code more maintainable and testable.
+{{/* Retrieve password from existing secret */}} +{{- define "common.secrets.passwords.fromExistingSecret" -}} + {{- $secretData := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret).data -}} + {{- if and $secretData (hasKey $secretData .key) -}} + {{- index $secretData .key | b64dec -}} + {{- else -}} + {{- printf "" -}} + {{- end -}} +{{- end -}} +{{/* Get password from provided values */}} +{{- define "common.secrets.passwords.fromProvidedValues" -}} + {{- $providedPasswordKey := include "common.utils.getKeyFromList" (dict "keys" .providedValues "context" .context) -}} + {{- $providedPasswordValue := include "common.utils.getValueFromKey" (dict "key" $providedPasswordKey "context" .context) -}} + {{- if $providedPasswordValue -}} + {{- printf "%s" $providedPasswordValue -}} + {{- else -}} + {{- printf "" -}} + {{- end -}} +{{- end -}} +{{/* Generate new random password */}} +{{- define "common.secrets.passwords.generateNew" -}} + {{- $password := "" -}} + {{- if .strong -}} + {{/* Strong password generation logic */}} + {{- else -}} + {{- $password = randAlphaNum .passwordLength -}} + {{- end -}} + {{- printf "%s" $password -}} +{{- end -}} {{- define "common.secrets.passwords.manage" -}} {{/* Main logic using the subfunctions */}} {{- end -}}This is just a conceptual approach - implementing it would require adjusting the full logic flow.
157-168: Secret lookup function could handle non-existent secrets more gracefullyThe
common.secrets.lookupfunction checks if a secret exists and returns either the value from the secret or a default value. It could be improved to handle errors more gracefully.Consider adding explicit error handling for when lookup fails (not just when the key doesn't exist):
{{- define "common.secrets.lookup" -}} {{- $value := "" -}} - {{- $secretData := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret).data -}} + {{- $secretObj := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret) -}} + {{- $secretData := "" -}} + {{- if $secretObj -}} + {{- $secretData = $secretObj.data -}} + {{- end -}} {{- if and $secretData (hasKey $secretData .key) -}} {{- $value = index $secretData .key -}} {{- else if .defaultValue -}} {{- $value = .defaultValue | toString | b64enc -}} {{- end -}} {{- if $value -}} {{- printf "%s" $value -}} {{- end -}} {{- end -}}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_postgresql.tpl (1)
90-102: Correct the “postgressPassword” spelling for consistency.
The function name and references would be clearer as "postgresPassword" to match the usual spelling and reduce the chance of confusion.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/Chart.lockis excluded by!**/*.lock
📒 Files selected for processing (79)
packages/core/platform/bundles/paas-full.yaml(1 hunks)packages/core/platform/bundles/paas-hosted.yaml(1 hunks)packages/extra/monitoring/Chart.yaml(1 hunks)packages/extra/monitoring/templates/vpa.yaml(1 hunks)packages/extra/versions_map(1 hunks)packages/system/vertical-pod-autoscaler/Chart.yaml(1 hunks)packages/system/vertical-pod-autoscaler/Makefile(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/.helmignore(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/Chart.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/LICENSE(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/.helmignore(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/Chart.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_affinities.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_capabilities.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_compatibility.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_errors.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_images.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_ingress.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_labels.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_names.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_resources.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_secrets.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_storage.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_tplvalues.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_utils.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_warnings.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_cassandra.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mariadb.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mongodb.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mysql.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_postgresql.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_redis.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_validations.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/ci/default-values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/NOTES.txt(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/metrics-service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/pdb.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/tls-secret.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/job.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/metrics-service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/servicemonitor.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/pod.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/values.yaml(1 hunks)
✅ Files skipped from review due to trivial changes (9)
- packages/extra/monitoring/Chart.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/NOTES.txt
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/values.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/.helmignore
- packages/system/vertical-pod-autoscaler/Chart.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/.helmignore
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/LICENSE
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/ci/default-values.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/Chart.yaml
🧰 Additional context used
🪛 YAMLlint (1.35.1)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrolebinding.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/pdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/tls-secret.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 13-13: wrong indentation: expected 2 but found 4
(indentation)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/job.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrole.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrolebinding.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrole.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/metrics-service.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/servicemonitor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/metrics-service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/pod.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
🪛 LanguageTool
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md
[grammar] ~43-~43: Only “latest” (without ‘most’) is used to write the superlative.
Context: ...isting my-release deployment with the most latest release of the chart. TIP: Use `he...
(MOST_SUPERLATIVE)
[uncategorized] ~53-~53: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...caler-1.3.0 Information about services are no more injected into pod's environment...
(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~53-~53: You might be missing the article “the” here.
Context: ...bout services are no more injected into pod's environment variable. ### Upgrading ...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[style] ~67-~67: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ender.metrics.service.ports.metrics. - Parameter updater.metrics.service.port` has been...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~74-~74: You might be missing the article “the” here.
Context: ...s now configured in image.registry. - Parameter imagePullSecrets has been renamed `gl...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[grammar] ~91-~91: The word ‘pre-install’ is not a noun.
Context: ...ons are now created and upgraded with a pre-install/pre-upgrade job. ### Upgrading to vers...
(A_INSTALL)
[uncategorized] ~458-~458: You might be missing the article “the” here.
Context: ...CENSE). It also uses source code under Apache 2.0 License from the [Bitnami repositor...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md
[uncategorized] ~31-~31: Possible missing comma found.
Context: ... This chart provides a common template helpers which can be used to develop new charts...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~140-~140: Did you mean the adverb “sometimes” (= occasionally)?
Context: ...tive data for a deployment in a secret, some times we want to give to users the possibilit...
(SOME_TIMES)
[uncategorized] ~184-~184: A comma might be missing here.
Context: ... }} If we force those values to be empty we will see some alerts console hel...
(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
[uncategorized] ~205-~205: This verb may not be in the correct tense. Consider changing the tense to fit the context better.
Context: ... - Previous versions of this Helm Chart use apiVersion: v1 (installable by both H...
(AI_EN_LECTOR_REPLACEMENT_VERB_TENSE)
[uncategorized] ~207-~207: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...fields present in the Chart.yaml file has been ordered alphabetically in a homoge...
(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[style] ~212-~212: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... you shouldn't face any issues - If you want to upgrade to this version using Helm v2, ...
(REP_WANT_TO_VB)
🪛 markdownlint-cli2 (0.17.2)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md
7-7: Trailing punctuation in heading
Punctuation: ';'
(MD026, no-trailing-punctuation)
10-10: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
11-11: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
29-29: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
30-30: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
40-40: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
51-51: Bare URL used
null
(MD034, no-bare-urls)
108-108: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
118-118: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
126-126: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
127-127: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
🔇 Additional comments (137)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrole.yaml (1)
1-26: ClusterRole implementation looks goodThe template correctly creates a ClusterRole with appropriate permissions for managing CRDs when
.Values.crds.enabledis true. The implementation includes:
- Dynamic API version based on capabilities
- Proper naming using helper functions
- Configurable labels and annotations
- Appropriate Helm hooks for lifecycle management
- Correct permissions for managing CRDs
The YAML static analysis warnings about indentation are false positives; the indentation is correct for Helm templates.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/extra/versions_map (1)
32-33: Version update looks goodThe changes properly update the monitoring package versioning:
- Assigning a specific commit hash to version 1.8.1
- Adding a new version 1.9.0 as HEAD
This is consistent with standard version management practices.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml (2)
11-16: Well-structured Helm hook configurationThe use of pre-install and pre-upgrade hooks with appropriate delete policies ensures this ClusterRoleBinding will be established before other resources are created and properly cleaned up during upgrades or reinstalls.
4-24:Details
✅ Verification successful
Verify corresponding ClusterRole definition exists
This ClusterRoleBinding references a ClusterRole with the same name. Ensure that the corresponding ClusterRole is properly defined elsewhere in the chart, as this binding won't work without it.
🏁 Script executed:
#!/bin/bash # Check if the corresponding ClusterRole exists in the chart echo "Checking for ClusterRole definition for: $(grep -A 1 "name: {{" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml | tail -1 | tr -d ' ')" echo "======" grep -r "kind: ClusterRole" --include="*.yaml" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/ echo "======" echo "Checking for ServiceAccount definition:" grep -r "kind: ServiceAccount" --include="*.yaml" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/Length of output: 1380
Action Required: Confirmed ClusterRole Definition Exists
The corresponding ClusterRole is defined in the chart (see
templates/crds/clusterrole.yaml), and the ServiceAccount is also present. No further changes are needed.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/pdb.yaml (2)
22-24:Details
✅ Verification successful
Confirm selector labels match deployment
Ensure that the selector labels used here match those defined in the admission controller deployment template. Otherwise, the PDB won't protect the intended pods.
🏁 Script executed:
#!/bin/bash # Compare selector labels with deployment labels echo "Checking admission controller deployment labels:" if [ -f packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml ]; then grep -A 10 "matchLabels:" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml echo "======" echo "Checking helper function for selectorLabels:" grep -r "vertical-pod-autoscaler.admissionController.selectorLabels" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/ fiLength of output: 2728
Selector labels consistency verified
The script output confirms that both the PDB and the admission controller deployment are using the same helper function (
vertical-pod-autoscaler.admissionController.selectorLabels), ensuring that the selector labels match. No further modifications are required.
16-21:Details
❓ Verification inconclusive
Validate PDB configuration in values.yaml
PodDisruptionBudgets should specify either
minAvailableormaxUnavailable, but not both simultaneously. While this template allows for configuring either option, ensure the values file doesn't enable both properties at the same time as this would result in an invalid resource.
🏁 Script executed:
#!/bin/bash # Check the default values for PDB configuration echo "Checking PDB configuration in values.yaml:" if [ -f packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml ]; then echo "Extracting admission controller PDB configuration:" grep -A 10 "admissionController:" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml | grep -A 10 "pdb:" | grep -E "minAvailable|maxUnavailable" else echo "values.yaml not found" fiLength of output: 476
Action Required: Validate PDB Settings in values.yaml
Please ensure that your values.yaml file under
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler
does not enable bothminAvailableandmaxUnavailableat the same time. The PodDisruptionBudget must specify either one or the other to avoid creating an invalid resource. Note that our initial automated check returned no output, so please manually verify that the defaults or any user modifications don’t inadvertently set both values simultaneously.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_storage.tpl (1)
8-21: Well-designed storage class helper functionThis storage class helper follows Helm best practices with a clear fallback mechanism:
- Uses global storage class if defined
- Falls back to component-specific storage class
- Falls back to global default storage class
- Handles the special case of
-to indicate no storage class should be usedThe implementation is robust and reusable across different chart components.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrolebinding.yaml (1)
4-21:Details
✅ Verification successful
Verify referenced resources exist
This ClusterRoleBinding references two other resources that should exist:
- A ClusterRole with the same name as this binding
- A ServiceAccount determined by the helper function
vertical-pod-autoscaler.updater.serviceAccountNameEnsure both are properly defined elsewhere in the chart.
🏁 Script executed:
#!/bin/bash # Check if the corresponding ClusterRole exists echo "Checking for ClusterRole definition for the updater component:" grep -r "kind: ClusterRole" --include="*.yaml" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/ echo "======" echo "Checking for ServiceAccount definition:" grep -r "kind: ServiceAccount" --include="*.yaml" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/ echo "======" echo "Checking serviceAccountName helper function:" grep -r "define \"vertical-pod-autoscaler.updater.serviceAccountName\"" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/Length of output: 1632
Resource References Verified and Consistent
- The ClusterRole is defined in
clusterrole.yamlfor the updater component.- The ServiceAccount is defined in
serviceaccount.yaml.- The helper function
vertical-pod-autoscaler.updater.serviceAccountNameis properly defined in_helpers.tpl.No further changes are necessary.
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml (2)
1-3: Helm Templating for PDB Resource Initialization
The conditional block using.Values.recommender.pdb.createand the dynamic inclusion of the API version and kind appear correctly implemented. The YAMLlint error on line 1 is most likely a false positive due to Helm’s templating syntax.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
14-24: PDB Specification Setup
The spec block conditionally includesminAvailableandmaxUnavailablebased on Helm values and correctly sets the selector using a template reference. Double-check that the provided values in.Values.recommender.pdbyield the intended behavior at runtime.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml (5)
1-2: Conditional Enabling of ServiceMonitor
The nested conditional checks for.Values.updater.enabledand.Values.updater.metrics.serviceMonitor.enabledensure that the ServiceMonitor resource is created only when metrics are enabled. This approach is sound.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
3-8: API Version and Basic Metadata Initialization
The API version and kind declarations, along with metadata such as name and namespace (using a safe default withquote), are well configured.
16-19: Conditional Annotations Merging
The annotations block smartly merges ServiceMonitor–specific annotations with global ones using a helper. Confirm that the merged annotations render as intended in the final YAML.
20-41: Endpoint and Spec Configuration
The spec configuration correctly handles an optionaljobLabeland defines the endpoints for scraping metrics. The conditional inclusion of parameters likeinterval,scrapeTimeout,honorLabels,metricRelabelings, andrelabelingsprovides flexibility. Ensure that the output from thenindentcalls for YAML formatting is as expected.
42-47: Namespace and Pod Selector Setup
The namespaceSelector (matching the release namespace) and the pod selector (using templated labels) are properly defined to ensure the ServiceMonitor targets the correct pods.packages/core/platform/bundles/paas-full.yaml (1)
369-376: New Release Configuration for Vertical Pod Autoscaler
A new release entry forvertical-pod-autoscalerhas been added with appropriate attributes: releaseName, chart, namespace, privileged flag, and a dependency onmonitoring-agents. Verify that the chart name (cozy-vertical-pod-autoscaler) and namespace align with your deployment conventions, and that the dependency onmonitoring-agentsmeets your orchestration requirements.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml (2)
1-3: Conditional ServiceAccount Creation
The ServiceAccount resource is conditionally rendered based on the.Values.crds.enabledflag. API version and kind are appropriately declared.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
11-16: Annotations and Helm Hook Configuration
The annotations correctly configure Helm hooks for pre-install and pre-upgrade events and include a hook deletion policy. Merging of common annotations is handled neatly.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/Chart.yaml (4)
1-5: Chart Metadata and Annotations Overview
The annotations include a signing key and specify the supported Kubernetes version. The API version is set to v2, and basic chart metadata is well defined.
6-13: API Version, AppVersion, and Dependency Setup
The chart definesappVersionand specifies a dependency on the "common" chart from Bitnami with a fixed version. The description succinctly outlines the chart’s purpose.
14-18: Chart Branding and Maintainer Details
The home URL, icon, and maintainer information are clearly specified, which aids in chart discovery and support.
19-23: Chart Identification and Versioning
The chart namevertical-pod-autoscaler, source links, and version (10.0.0) are correctly set. Ensure that theappVersion(1.3.0) consistently reflects the actual application version.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml (1)
1-49: Well-structured ServiceMonitor implementationThe ServiceMonitor is correctly configured with conditional rendering based on both
admissionController.enabledandadmissionController.metrics.serviceMonitor.enabled. The template includes comprehensive customization options for metrics collection, including interval, timeout, relabeling configurations, and proper namespace selector setup.Don't worry about the YAMLlint indentation warnings - they're false positives that don't account for Helm templating conventions.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml (1)
1-17: ServiceAccount template looks goodThe ServiceAccount is properly configured with conditional rendering based on
updater.enabledandupdater.serviceAccount.create. I like how you've handled annotations merging between service-specific and common annotations.The YAMLlint indentation warnings can be safely ignored as they're false positives that don't account for Helm templating conventions.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml (1)
1-22: Properly configured ClusterRoleBindingThe ClusterRoleBinding is correctly set up with proper conditional rendering, appropriate roleRef configuration, and correct subject binding to the ServiceAccount. This will grant the necessary permissions for the admission controller to function correctly.
The YAMLlint indentation warnings are false positives and can be safely ignored.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/core/platform/bundles/paas-hosted.yaml (1)
251-256: Good configuration for VPA integrationThe new vertical-pod-autoscaler release is properly configured with the correct chart reference, namespace, and privilege settings. Setting
privileged: trueis appropriate given the VPA's functionality.The dependency on
monitoring-agentsmakes sense as it ensures monitoring is available before deploying the VPA.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_resources.tpl (1)
1-50:Details
❓ Verification inconclusive
Well-defined resource presets with one concern
The
common.resources.presettemplate function provides a nice abstraction for defining resource requirements based on predefined sizes. The implementation includes proper error handling for invalid types and a good range of preset options.One concern: there's a significant discrepancy between ephemeral storage requests (50Mi) and limits (2Gi) across all presets. This 40x difference might lead to resource contention on nodes with limited storage if many pods are scheduled.
🏁 Script executed:
#!/bin/bash # Check if there are other resource presets in the codebase for comparison echo "Searching for other resource preset patterns in the codebase..." rg -A 2 -B 2 "ephemeral-storage" --type yamlLength of output: 48628
Resource Preset Abstraction – Verify Ephemeral Storage Settings
The template function
common.resources.presetcleanly abstracts resource configurations and handles invalid keys well. However, the presets uniformly setephemeral-storagerequests at 50Mi and limits at 2Gi—a 40× gap that could lead to node contention in environments with tight storage resources. This discrepancy appears consistent, and similar charts only indicate support for the ephemeral-storage key without overriding these values. Please verify that this ratio is intentional and aligns with your operational requirements.
- File:
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_resources.tpl- Lines: 1-50
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_errors.tpl (1)
1-28: Well-structured error handling mechanism for empty passwords during upgrades.This template provides a robust mechanism for detecting and reporting empty passwords during chart upgrades. The error messages are informative and include a link to troubleshooting documentation, which will significantly improve the user experience when dealing with credential-related issues.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml (1)
1-26: PodDisruptionBudget implementation for the updater component looks good.The PDB is appropriately conditional based on configuration values and includes all necessary fields. This will help maintain high availability of the vertical-pod-autoscaler updater component during cluster operations.
Note: The static analysis warnings about indentation can be safely ignored as the template follows standard Helm chart indentation patterns.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/serviceaccount.yaml (1)
1-16: ServiceAccount Template – Conditional Rendering & Annotation MergingThe template correctly wraps the ServiceAccount definition within the conditional block using
.Values.recommender.serviceAccount.create. The merge for annotations from both.Values.recommender.serviceAccount.annotationsand.Values.commonAnnotationsis implemented as expected.Note: The YAMLlint errors (e.g. syntax error at line 1 and indentation warnings at lines 9–10) are likely false positives due to Helm’s templating syntax. Please verify the rendered output with
helm templateto ensure proper YAML formatting.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/job.yaml (2)
1-17: Job Resource Template – Conditional Inclusion & Hook AnnotationsThe Job resource is conditionally created based on
.Values.crds.enabled, and the metadata (name, labels) is properly derived from template functions. The hook annotations for pre-install and pre-upgrade (lines 12–13) are clearly specified and conform to typical Helm practices.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
18-31: Pod Template – Labels & Annotation BlockThe nested metadata under the pod template (lines 19–31) uses multiple conditional blocks to merge labels and annotations. Given the depth of indentation and templating (with
nindent), please ensure that the rendered YAML’s indentation is as expected. Runninghelm templatewould be very useful here.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/metrics-service.yaml (2)
1-13: Metrics Service Metadata – Labels and AnnotationsThe Service metadata is structured to include a dynamic name, merged labels (using
vertical-pod-autoscaler.recommender.labelsand common labels), and conditional annotations. The static analysis warnings regarding indentation on lines 7–9 are likely due to the templating syntax; please verify the final rendered YAML output.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
14-32: Service Spec – Type, IP Configurations & Port DefinitionsThe service specification correctly handles different conditions:
- It supports custom service types, including conditional handling for
ClusterIPand its correspondingclusterIPfield.- Optional fields for
ipFamilyPolicyandipFamiliesare managed appropriately.- The ports section cleanly exposes the metrics port with a selector pulled from a template.
This block appears solid; just ensure that the conditional logic behaves correctly in all configuration scenarios.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/tls-secret.yaml (2)
1-5: TLS Secret – Certificate Generation & Conditional Secret CreationThe template sets up the certificate generation logic correctly using
genCAandgenSignedCert, and conditionally renders the Secret only when.Values.admissionController.tls.existingSecretis not provided. The use of a fixed validity period (365 days) should be reviewed against your security policies.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
6-17: Secret Resource – Metadata, Labels & AnnotationsThe Secret resource definition (lines 6–17) correctly leverages templating to populate the metadata fields. As with the other files, YAMLlint warnings (syntax error on line 1 and indentation warnings on lines similar to 13–14) are expected with Helm templates. Running
helm templatewill help confirm that the final rendered Secret is properly indented and valid YAML.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 13-13: wrong indentation: expected 2 but found 4
(indentation)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml (2)
1-10: ConfigMap Template – Conditional Inclusion & LabelsThe ConfigMap is conditionally created based on
.Values.crds.enabledand follows the standard pattern for merging labels, including common labels if defined. As with other templated files, static analysis warnings for syntax and indentation (e.g. on line 1 and lines 9–10) can be considered false positives due to Helm syntax.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-22: ConfigMap Data – Dynamic Population from CRD FilesThe
datablock leverages a loop over files in thefiles/crds/*directory, usingtplandnindentto render each file's content appropriately. This approach is clean and modular. Please verify that all expected files are correctly picked up and that the rendered ConfigMap maintains valid YAML structure.packages/system/vertical-pod-autoscaler/values.yaml (1)
22-29: Admission controller resource configuration looks goodThe memory limits (256Mi) are higher than requests (50Mi), which allows for efficient resource allocation. The CPU request of 50m seems appropriate for the admission controller component.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_compatibility.tpl (2)
8-17: Well-implemented OpenShift detection functionThe isOpenshift function is well-implemented, checking for the OpenShift API version in a clean way. Clear documentation is provided on how to use this function.
19-42: Comprehensive security context adaptation for cross-platform compatibilityThe renderSecurityContext function handles compatibility issues between different Kubernetes platforms well, especially for OpenShift. It correctly:
- Removes incompatible user/group settings
- Handles empty seLinuxOptions to avoid validation issues
- Adjusts fields for privileged containers
The function is also well-documented with clear usage instructions.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml (1)
11-39: Well-designed service configuration with appropriate conditional logicThe service configuration has:
- Good use of conditional logic for annotations and optional parameters
- Proper selection of service type and port configuration
- Appropriate selector labels using the template helper
This implementation follows Kubernetes and Helm best practices.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_tplvalues.tpl (2)
1-24: Well-implemented template rendering function with clear documentationThe common.tplvalues.render function is well-designed with:
- Proper type checking and conversion
- Support for scoped template rendering
- Clear documentation and usage examples
This utility function will be valuable for handling complex templating scenarios throughout the chart.
26-38: Effective merge function for template valuesThe common.tplvalues.merge function correctly implements:
- Merging of rendered template values
- Adherence to Sprig library merge precedence
- Proper rendering of each value before merging
The documentation includes clear usage examples, making it easy for other developers to use this function.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/metrics-service.yaml (1)
1-33: Well-structured metrics service for VPA admission controllerThis service definition follows Kubernetes and Helm best practices with:
- Conditional creation based on whether the admission controller is enabled
- Proper template functions for consistent naming and labeling
- Flexible configuration for service type, IP settings, and port configuration
- Clear selector for routing traffic to the appropriate pods
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml (1)
13-149: Comprehensive RBAC permissions for VPA recommenderThe ClusterRole defines appropriate permissions for the recommender component, with well-organized rules grouped by functionality:
- Metrics reading capabilities from the metrics.k8s.io API
- Pod, node, and limitrange access for resource analysis
- Permissions to manage both legacy (poc.autoscaling.k8s.io) and current (autoscaling.k8s.io) VPA resources
- Access to various workload resources for target reading
- Leader locking permissions for high availability
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/pod.yaml (1)
1-36:Details
❓ Verification inconclusive
Well-configured test Pod for VPA validation
The test Pod is appropriately defined with:
- Proper Helm test hook annotations
- Image configuration via templating
- Volume mounts for test resources and admission controller TLS certificates
- "Never" restart policy suitable for test resources
Ensure that the admission controller TLS secret referenced in the volume mount will be available when tests run, especially if tests can execute before the admission controller is fully deployed.
🏁 Script executed:
#!/bin/bash # Check if the TLS secret template exists and what conditions control its creation grep -A 10 "name: {{ include \"vertical-pod-autoscaler.admissionController.tls.secretName\" . }}" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/ --include="*.yaml"Length of output: 344
Attention: Confirm TLS Secret Deployment Timing
The VPA test Pod is well-configured, with correct test hook annotations, dynamic image templating, proper volume mounts (for both test resources and the admission controller TLS certificate), and a "Never" restart policy. However, please ensure that the TLS secret referenced via
{{ include "vertical-pod-autoscaler.admissionController.tls.secretName" . }}
is indeed defined and available at runtime. This is particularly important if there's a chance the test Pod could run before the admission controller (and its corresponding TLS secret) is fully deployed.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_ingress.tpl (1)
1-73: Well-designed ingress helper templates with excellent backwards compatibilityThese template functions provide robust support for ingress configuration across different Kubernetes versions:
- The backend template handles both v1beta1 and v1 API versions correctly
- Type checking for service ports ensures proper formatting (string vs numeric)
- Version comparisons correctly detect feature support for pathType and ingressClassname
- The cert-manager detection function provides a clean way to check for TLS configuration
This is particularly valuable for ingress resources, which have undergone significant API changes across Kubernetes versions.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml (4)
15-53: Well-structured deployment spec with comprehensive configuration options.The deployment spec provides excellent flexibility with configurable replicas, selectors, and pod template. The conditional inclusion of various Kubernetes features (hostAliases, priorityClassName, etc.) makes this template highly adaptable to different environments.
54-81: Container configuration provides good security and environment flexibility.The container configuration includes proper security contexts and flexible environment variable configuration. The ability to source environment variables from ConfigMaps and Secrets is particularly useful for maintaining configuration separate from code.
119-140: Resource management and scheduling configuration looks good.The resource specification, volume mounts, node selection, affinity, and tolerations are all well-structured and provide good flexibility for deployment across different Kubernetes environments.
1-14:Details
✅ Verification successful
Metadata section looks good but watch out for indentation warnings.
The deployment metadata structure is well-defined with proper templating for API version, name, and labels. The conditional inclusion of common labels and annotations is a good practice.
🏁 Script executed:
#!/bin/bash # Check if the indentation in YAML files follows Helm's conventions # Looking for potential indentation issues in the recommender deployment echo "Checking indentation in deployment.yaml" grep -n "{{- include" packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml | head -10Length of output: 1343
Actionable Directive: Confirmed Correct Metadata Formatting and Indentation
The metadata section is properly structured with the correct use of Helm templating for API version, name, labels, and annotations. The grep output confirms that the
nindentdirectives (using values 4, 6, and 8 where needed) are consistently applied, so no immediate indentation issues are evident. Please remain attentive to any future changes that might trigger indentation warnings during linting.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/_helpers.tpl (1)
1-23: Helper templates for tests are well-organized and follow naming conventions.The test helper templates follow a consistent naming pattern and provide clear separation of concerns. The template functions will make it easier to maintain consistent naming and labeling across test resources.
packages/extra/monitoring/templates/vpa.yaml (2)
21-42:Details
❓ Verification inconclusive
VPA for vmselect has significantly higher resource allowances.
The vmselect VPA allows for up to 4000m CPU and 8Gi memory, which is twice the CPU and memory limit of vminsert. Ensure these limits align with the expected resource consumption patterns.
🏁 Script executed:
#!/bin/bash # Verify the existing resource requests/limits for vmselect to ensure VPA settings make sense echo "Checking existing resource configurations for vmselect-shortterm" fd --type f --extension yaml --extension yml "vmselect-shortterm" | xargs grep -A10 "resources:" | head -20Length of output: 244
Attention: Verify Resource Allowances for vmselect VPA
The VPA configuration in
packages/extra/monitoring/templates/vpa.yamlsets the maximum allowed resources for vmselect at 4000m CPU and 8Gi memory—double that of the vminsert settings. Our verification script did not yield any explicit resource configuration for thevmselect-shorttermStatefulSet, which means these boundaries have not been cross-checked against other definitions. Please confirm that these higher limits accurately reflect vmselect’s resource consumption patterns. If this disparity is intentional, consider adding clarifying documentation or inline comments; if not, adjust the values to ensure consistency across similar workloads.
43-63:Details
❓ Verification inconclusive
VPA for vmstorage has lower CPU minimum but higher memory minimum.
The vmstorage VPA has a lower minimum CPU (100m vs 250m) but higher minimum memory (512Mi vs 256Mi) compared to the other components. This looks intentional but worth confirming that these differences align with the expected resource usage patterns.
🏁 Script executed:
#!/bin/bash # Compare resource patterns across VictoriaMetrics components echo "Gathering existing resource configurations for VM components to compare patterns" echo "vmstorage resources:" fd --type f --extension yaml --extension yml "vmstorage-shortterm" | xargs grep -A10 "resources:" | head -10Length of output: 328
Attention: Confirm Resource Settings for vmstorage
The VPA configuration in
packages/extra/monitoring/templates/vpa.yaml(lines 43-63) sets a lower CPU minimum (100m) and a higher memory minimum (512Mi) compared to what we see for other components (typically around 250m CPU and 256Mi memory). Although this appears to be an intentional choice, please verify that these settings correctly align with the expected resource usage patterns for vmstorage.
- File:
packages/extra/monitoring/templates/vpa.yaml- Key differences:
- CPU (minAllowed): 100m (lower than expected)
- Memory (minAllowed): 512Mi (higher than expected)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml (4)
1-16: CRD metadata is well-defined with proper references and annotations.The CRD includes appropriate labels, annotations for API approval, and controller-gen version. This follows Kubernetes best practices for custom resource definitions.
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
17-25: Resource naming follows Kubernetes conventions with useful shortnames.The naming for the VerticalPodAutoscalerCheckpoint resource includes appropriate singular, plural, and list kinds, as well as a helpful shortname "vpacheckpoint".
26-127: V1 schema is comprehensive with well-documented fields.The v1 schema is thorough and includes detailed descriptions for all fields. The schema correctly captures the structure needed for VPA checkpoints, including histograms for resource usage and timestamps.
128-228: V1beta2 schema is maintained for backward compatibility.Including the v1beta2 schema with
served: falseandstorage: falseis a good practice for maintaining backward compatibility while clearly indicating that this version is deprecated.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml (1)
89-98:Details
❓ Verification inconclusive
Verify that the health check endpoint exists in the VPA updater
The health check paths are set to
/health-checkfor the liveness probe. Please verify that this endpoint actually exists in the VPA updater component.
🏁 Script executed:
#!/bin/bash # Check if the VPA updater documentation or source code mentions a health check endpoint rg -A 3 -B 3 "health-check|healthcheck" --type goLength of output: 51
Health Check Endpoint Verification Pending
The grep search for references to “/health-check” in the Go source code did not return any matches. This absence of evidence suggests that the endpoint might not be implemented, or it may be registered differently. Please manually verify the following:
- Confirm if the VPA updater actually registers an HTTP endpoint for
/health-check.- If the endpoint is missing, update the implementation or adjust the liveness probe configuration accordingly.
- Review the updater component’s documentation or source code for any alternate implementations of the health check functionality.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml (1)
87-101:Details
❓ Verification inconclusive
Verify pod eviction permissions scope
The ClusterRole includes permissions to create pod evictions, which is a powerful capability. Ensure this is the minimum required scope for the VPA updater component. Consider if this could be constrained further with additional conditions.
🏁 Script executed:
#!/bin/bash # Check VPA documentation or source about eviction permissions rg -A 5 -B 5 "pod.*eviction|eviction.*pod" --type mdLength of output: 49448
Action Required: Confirm Minimum Required Pod Eviction Permissions
The ClusterRole in
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml
(lines 87–101) currently grants the VPA updater permission to create pod evictions. Given the sensitivity of this operation, please verify that this indeed reflects the minimum required scope according to the upstream VPA guidelines.
- Check: Confirm that the VPA updater component does not need broader eviction permissions than granted.
- Review: Verify against upstream VPA documentation and security best practices that no additional constraints (such as conditions or restricted API groups) are needed.
If further restrictions are possible or documented, please adjust the permissions accordingly and document the rationale.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/_helpers.tpl (1)
1-31: LGTM! Well-structured template helpersThe helper template functions are well-organized, follow consistent naming conventions, and properly implement the component labeling hierarchy. This will ensure consistent labeling across all CRD resources.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_validations.tpl (1)
1-51: LGTM! Comprehensive validation templatesThe validation templates are well-documented with good usage examples and will help ensure required values are properly set. The error messages are particularly helpful as they include instructions for fixing the issues.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_cassandra.tpl (3)
22-30: LGTM: Password validation logic is well-implemented.The validation conditional logic correctly checks for the absence of existing secrets and whether Cassandra is enabled before performing the validation checks.
1-15: LGTM: Well-documented template header.The template header clearly explains the purpose, usage, and parameters, making it easy for other developers to understand how to use this template.
59-59:Details
❓ Verification inconclusive
Verify
enabledvalue logic for non-subchart deployments.In the
common.cassandra.values.enabledtemplate, the non-subchart case returns the inverse of.context.Values.enabled. This seems counter-intuitive - typically an "enabled" function would return the value directly rather than its negation. Please confirm this logic is intentional.
🏁 Script executed:
#!/bin/bash # Find places where this template is used to understand the expected behavior rg -A 3 "common.cassandra.values.enabled" --glob "*.tpl" --glob "*.yaml"Length of output: 3987
Double-check Inversion in Cassandra Enabled Logic
It appears that for non‐subchart deployments in the vertical‐pod‐autoscaler chart, the helper returns the negation of
.context.Values.enabledinstead of directly using a property like.context.Values.cassandra.enabled(as seen in other charts such as kubeapps/redis). Please verify whether inverting the flag is intentional. If this inversion was deliberate, adding a clarifying comment in the template might help future maintainers. Otherwise, consider aligning it with the behavior in other charts.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_images.tpl (3)
11-26: LGTM: Comprehensive image construction template.The template handles all edge cases for constructing image references, including support for both tags and digests, and proper fallback for registry values.
95-108: Well-implemented semantic version extraction with sensible fallback.The implementation correctly extracts semantic versions from image tags and falls back to chart AppVersion when needed. The regular expression pattern for semantic versioning is properly referenced and implemented.
65-93: LGTM: Enhanced pull secrets implementation with template rendering.This template extends the basic pull secrets functionality to support rendering values as templates, which provides greater flexibility for dynamic configurations.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml (1)
1-33: LGTM: Well-structured metrics service configuration.The service definition is correctly implemented with:
- Conditional creation based on updater enablement
- Proper template inclusion for labels and annotations
- Conditional IP family and cluster IP configuration
- Well-defined port configuration for metrics endpoint
The static analysis warnings about indentation can be ignored as they're false positives in the context of Helm templates.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml (4)
101-111: LGTM: Properly configured liveness probe.The liveness probe is well-implemented with appropriate endpoint and configurable timing parameters.
68-76: LGTM: Comprehensive container arguments with extension support.The admission controller arguments are properly configured with:
- Well-defined port and address configuration
- TLS certificate paths
- Support for additional custom arguments through values
156-159: LGTM: Secure TLS secret volume configuration.The TLS secret volume is properly configured to be mounted into the container for secure certificate access.
31-39: Smart checksum annotation for TLS secret.Including a checksum annotation for the TLS secret is a great practice that ensures pods are restarted when TLS certificates change. This prevents certificate-related outages after renewal.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_labels.tpl (1)
1-47: LGTM: Well-structured template functions for Kubernetes labelsThe implementation follows Kubernetes best practices for label management. Both functions (
common.labels.standardandcommon.labels.matchLabels) correctly handle custom labels while preserving essential metadata, and the conditional logic properly checks for required context.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml (1)
371-620: Well-handled version deprecationGood job properly marking the v1beta2 version as deprecated and including a clear deprecation warning. This follows best practices for API lifecycle management.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/_helpers.tpl (1)
1-53: LGTM: Well-designed template helper functionsThe helper functions are well-implemented following Helm best practices:
- Proper truncation at 63 characters to adhere to Kubernetes name limits
- Appropriate handling of name overrides
- Clean management of chart version and application labels
These templates will provide consistent naming and labeling across all VPA resources.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/_helpers.tpl (2)
42-48: LGTM: Properly handling service account creationThe service account naming logic correctly handles both scenarios - creating a new service account or using an existing one. The default fallback to the component's full name when creating follows best practices.
53-59: LGTM: Secure management of TLS secret namesThe TLS secret naming logic appropriately handles both using existing secrets and generating new ones with consistent naming conventions.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mysql.tpl (1)
1-108: Well-structured MySQL validation template.The template provides comprehensive validation for MySQL passwords and includes helpful auxiliary functions for different deployment scenarios. The implementation follows best practices with clear documentation and proper error handling.
A few observations:
- Good use of conditional checks to determine when validation is needed
- Proper handling of subchart vs direct chart scenarios
- Clear documentation with usage examples for each function
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_utils.tpl (1)
1-77: Well-implemented utility functions for Helm templates.These utility functions provide essential Helm templating capabilities such as secret retrieval, environment variable conversion, value fetching, and checksum calculation. The code is clean and well-documented with clear usage examples.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml (10)
1-30: LGTM - Good organization of global and common parameters.The values file follows best practices with descriptive parameter documentation and clear organization of configuration sections.
36-109: Well-structured admission controller configuration.The admission controller section provides comprehensive configuration options including replicas, image settings, security contexts, and network settings. Each parameter is well-documented.
110-225: Properly documented pod security and networking settings.The configuration includes appropriate security settings and network options, with defaults that follow Kubernetes best practices.
226-244: Resource configuration follows best practices.Resource configuration is properly structured with commented examples for requests and limits. The node placement configuration (nodeSelector, tolerations, affinity) follows standard patterns.
262-314: Well-structured metrics configuration for Prometheus integration.The metrics configuration includes service monitor settings for Prometheus integration, which is essential for monitoring the VPA components.
315-327: Secure TLS configuration with proper secret handling.The TLS configuration provides appropriate options for certificate management, including the ability to use existing secrets.
330-619: Recommender configuration mirrors admission controller structure.The recommender component configuration follows the same pattern as the admission controller, ensuring consistency across components. All expected configuration options are present.
622-883: Updater configuration is complete and consistent.The updater component configuration follows the same comprehensive pattern as the other components, maintaining consistency throughout the chart.
886-947: CRDs configuration is properly isolated.The CRDs section properly isolates the configuration for Kubernetes custom resource definitions, which is a best practice for Helm charts.
951-966: Test configuration is properly defined.The test image configuration is properly defined, enabling automated testing of the deployed components.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mongodb.tpl (1)
1-114: Well-structured MongoDB validation template.The template provides comprehensive validation for MongoDB passwords and includes appropriate auxiliary functions for different deployment architectures. The implementation follows best practices with clear documentation and proper error handling.
A few observations:
- Good handling of authentication status checks
- Proper validation for different MongoDB architectures (standalone vs replicaset)
- Consistent pattern with the MySQL validation template
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_names.tpl (5)
10-12: Helm naming override approach is aligned with best practices.
The logic incommon.names.namematches standard Helm conventions for name overrides, applying truncation and suffix trimming to meet Kubernetes naming constraints.
17-19: Consider verifying the need to include chart version in naming.
Including a chart version in resource names can cause churn in ephemeral environments. Verify whether dynamically updated dependencies might break references if the name changes too often.
26-37: Release name handling is consistent.
This fallback properly checks whether the release name is already included in the chart name before concatenating, preventing redundant text. Nicely done.
46-57: Confirm dependency naming fallback.
Ensure that for dependencies lacking an explicitfullnameOverrideornameOverride, this logic does not produce collisions with similarly named subcharts or dependencies in the same release.
62-71: Namespace override approach is robust.
Overriding the namespace for multi-namespace deployments is a common pattern, ensuring flexibility in multi-tenant or multi-environment setups.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_affinities.tpl (6)
8-23: Validate behavior for empty .values array inputs.
If.valuesis unspecified or empty, the templated YAML may still render partial structures without the intended keys. Confirm that your chart usage accounts for these scenarios and handles them gracefully.
29-39: NodeAffinity (hard) logic looks correct.
This YAML block properly sets up the requiredDuringSchedulingIgnoredDuringExecution rule, aligning with standard hard-affinity usage.
41-51: NodeAffinity aggregator function is coherent.
Switching between “soft” and “hard” affinity based on.typeis well-structured and readable.
65-95: Check optional component labeling in soft PodAffinity.
If.componentis empty, the chart omits the label. Confirm that the resulting labelSelector still produces valid YAML. This appears correct, but a quick test would be prudent.
101-127: Hard PodAffinity is correctly set up.
Using requiredDuringSchedulingIgnoredDuringExecution with the appropriate label selectors and topology key is standard practice for enforced affinity rules.
129-139: PodAffinity aggregator function is concise.
This method consolidates soft vs. hard logic effectively, promoting DRY code.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_postgresql.tpl (3)
16-34: PostgreSQL password validation logic is solid.
It checks whether an existing secret is provided and handles replication passwords conditionally, ensuring minimal misconfiguration risk.
74-79: Confirm the negation logic in postgresql.enabled.
When not a subchart, this code returnsnot .context.Values.enabled. Verify that this intentional inversion does not lead to unexpectedly disabling PostgreSQL.
128-134: Replication password key usage is consistent with subchart logic.
The function elegantly distinguishes between subchart usage versus top-level usage.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/_helpers.tpl (6)
5-7: Good use of truncated naming.
This function correctly references the main chart's fullname and appends-updater.
12-14: Metrics name derivation looks fine.
Concise logic for suffixing-metricsensures a consistent naming pattern.
19-21: Consistent labeling.
Usingapp.kubernetes.io/component: updateradheres to recommended Kubernetes labeling conventions.
26-29: Properly aggregating labels.
Combining shared labels with component-specific labels is a good approach for maintainability.
34-37: Selector labels.
Merging the base selector labels with updater-specific component labels ensures correct resource matching.
42-48: Service account naming strategy is standard.
Falling back to thedefaultservice account if creation is disabled is a common Helm pattern.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/_helpers.tpl (6)
5-7: Full name logic follows best practices.
Appending-recommenderand trimming extra characters is consistent with typical Helm patterns.
12-14: Metrics naming looks clear.
The additional-metricssuffix ensures a distinct resource name for metrics.
19-21: Appropriate component labels.
Definingapp.kubernetes.io/component: recommenderis aligned with standard labeling.
26-29: Correct approach to merging labels.
Leveraging the main chart’s labels and adding recommender labels keeps labeling consistent.
34-37: Selector labels are well-defined.
Combining main selector labels with recommender-specific labels helps controllers distinctly identify these pods.
42-48: Service account resolution matches typical Helm usage.
The fallback to "default" when creation is disabled provides a graceful path for minimal setups.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_capabilities.tpl (19)
1-4: License header.
No code logic here; looks fine.
11-13: Kubernetes version fallback logic.
Uses.Capabilities.KubeVersion.Versionor.Values.kubeVersionfor overarching checks.
15-25: policy.apiVersion dynamically set.
Correctly usespolicy/v1beta1for <1.21 andpolicy/v1otherwise, mirroring official K8s versions.
27-37: networkPolicy.apiVersion appropriately determined.
Switching tonetworking.k8s.io/v1for >=1.7 is accurate.
39-50: cronjob.apiVersion checks.
Selectingbatch/v1beta1for <1.21 andbatch/v1otherwise aligns with K8s deprecation timelines.
51-62: daemonset.apiVersion usage.
extensions/v1beta1is correctly retained for older clusters.
63-74: deployment.apiVersion logic.
Conditionally pickingextensions/v1beta1orapps/v1matches best practices.
75-86: statefulset.apiVersion fallback.
Switching toapps/v1for >=1.14 is correct.
87-102: ingress.apiVersion resolution.
Correctly observes user-supplied apiVersion or transitions fromextensions/v1beta1tonetworking.k8s.io/v1.
103-114: rbac.apiVersion logic.
Manages older <1.17 clusters withrbac.authorization.k8s.io/v1beta1. Matches typical Helm patterns.
115-126: crd.apiVersion checks.
apiextensions.k8s.io/v1for >=1.19 is now standard.
127-138: apiService.apiVersion fallback.
Applyingapiregistration.k8s.io/v1beta1only for very old clusters (<1.10).
139-153: hpa.apiVersion switching.
Conditionally selectingautoscaling/v2beta1,autoscaling/v2beta2, orautoscaling/v2for target versions is correct.
155-169: vpa.apiVersion logic is well aligned.
Similar approach as HPA, catering to older clusters with the correct beta versions.
171-180: psp.supported helper.
Returning true for K8s <1.25 acknowledges PSP removal in 1.25. Good.
181-190: admissionConfiguration.supported guard.
Enabling it from K8s 1.23 onward is consistent with admission config documentation.
191-204: admissionConfiguration.apiVersion selection.
Uses alpha/beta/stable versions accurately across different cluster versions.
205-218: podSecurityConfiguration.apiVersion adaptation.
Correctly handles older alpha/beta vs. stable for K8s <1.25.
219-229: Helm version check.
Regex-based detection ensures usage of.Capabilities.HelmVersionfor Helm 3.3+.
| # VictoriaMetrics operator | ||
| helm repo add cowboysysop https://cowboysysop.github.io/charts/ | ||
| helm repo update cowboysysop | ||
| helm pull cowboysysop/vertical-pod-autoscaler --untar --untardir charts |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Comment doesn't match the actual chart being pulled
The comment refers to "VictoriaMetrics operator" but the command pulls the "vertical-pod-autoscaler" chart. This inconsistency adds to the confusion with the variable naming.
- # VictoriaMetrics operator
+ # Vertical Pod Autoscaler chart📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # VictoriaMetrics operator | |
| helm repo add cowboysysop https://cowboysysop.github.io/charts/ | |
| helm repo update cowboysysop | |
| helm pull cowboysysop/vertical-pod-autoscaler --untar --untardir charts | |
| # Vertical Pod Autoscaler chart | |
| helm repo add cowboysysop https://cowboysysop.github.io/charts/ | |
| helm repo update cowboysysop | |
| helm pull cowboysysop/vertical-pod-autoscaler --untar --untardir charts |
| export NAME=victoria-metrics-operator | ||
| export NAMESPACE=cozy-$(NAME) |
There was a problem hiding this comment.
Naming inconsistency between package purpose and variables
There appears to be a mismatch between the directory name (vertical-pod-autoscaler) and the NAME variable (victoria-metrics-operator). This inconsistency could lead to confusion or errors in deployment.
-export NAME=victoria-metrics-operator
-export NAMESPACE=cozy-$(NAME)
+export NAME=vertical-pod-autoscaler
+export NAMESPACE=cozy-$(NAME)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export NAME=victoria-metrics-operator | |
| export NAMESPACE=cozy-$(NAME) | |
| export NAME=vertical-pod-autoscaler | |
| export NAMESPACE=cozy-$(NAME) |
| labels: | ||
| {{- include "vertical-pod-autoscaler.recommender.labels" . | nindent 4 }} | ||
| {{- if .Values.commonLabels }} | ||
| {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | ||
| {{- end }} | ||
| {{- if .Values.commonAnnotations }} | ||
| annotations: {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 4 }} | ||
| {{- end }} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix YAML Templating Indentation Issues in Metadata Labels
The metadata’s labels block is triggering a YAMLlint error (e.g. on line 6) and several indentation warnings on lines 7–9. This is likely due to the use of leading hyphens (e.g. {{- ... }}) and an incorrect nindent level. Please review and adjust these templated directives so that the YAML structure is valid when rendered. For example, remove unnecessary “-” prefixes and set consistent indentation (e.g. using nindent 2 where appropriate) within the labels block.
A suggested change:
- labels:
- {{- include "vertical-pod-autoscaler.recommender.labels" . | nindent 4 }}
- {{- if .Values.commonLabels }}
- {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }}
- {{- end }}
- {{- if .Values.commonAnnotations }}
- annotations: {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 4 }}
- {{- end }}
+ labels:
+ {{ include "vertical-pod-autoscaler.recommender.labels" . | nindent 2 }}
+ {{- if .Values.commonLabels }}
+ {{ include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }}
+ {{- end }}
+ {{- if .Values.commonAnnotations }}
+ annotations: {{ include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 2 }}
+ {{- end }}Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
| {{- if .Values.recommender.metrics.serviceMonitor.enabled }} | ||
| apiVersion: monitoring.coreos.com/v1 | ||
| kind: ServiceMonitor | ||
| metadata: | ||
| name: {{ include "vertical-pod-autoscaler.recommender.fullname" . }} | ||
| namespace: {{ default .Release.Namespace .Values.recommender.metrics.serviceMonitor.namespace | quote }} | ||
| labels: | ||
| {{- include "vertical-pod-autoscaler.recommender.labels" . | nindent 4 }} | ||
| {{- if .Values.recommender.metrics.serviceMonitor.labels }} | ||
| {{- include "common.tplvalues.render" ( dict "value" .Values.recommender.metrics.serviceMonitor.labels "context" $ ) | nindent 4 }} | ||
| {{- end }} | ||
| {{- if .Values.commonLabels }} | ||
| {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | ||
| {{- end }} | ||
| {{- if or .Values.recommender.metrics.serviceMonitor.annotations .Values.commonAnnotations }} | ||
| {{- $annotations := include "common.tplvalues.merge" ( dict "values" ( list .Values.recommender.metrics.serviceMonitor.annotations .Values.commonAnnotations ) "context" . ) }} | ||
| annotations: {{- include "common.tplvalues.render" ( dict "value" $annotations "context" $ ) | nindent 4 }} | ||
| {{- end }} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Resolve YAML Templating and Indentation Warnings
YAMLlint is reporting a syntax error on line 1 and several indentation warnings (e.g. on lines 10–14) in this ServiceMonitor template. These issues often arise when Helm templating directives (with leading hyphens) disrupt YAML’s expected structure. Please consider:
• Removing or adjusting the leading “-” in directives (e.g. change {{- if … }} to {{ if … }} when appropriate).
• Verifying that nindent values correctly align the generated content under their parent keys.
Review the rendered output to ensure the final YAML is valid.
A possible diff adjustment for the opening condition:
-{{- if .Values.recommender.metrics.serviceMonitor.enabled }}
+{{ if .Values.recommender.metrics.serviceMonitor.enabled }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{- if .Values.recommender.metrics.serviceMonitor.enabled }} | |
| apiVersion: monitoring.coreos.com/v1 | |
| kind: ServiceMonitor | |
| metadata: | |
| name: {{ include "vertical-pod-autoscaler.recommender.fullname" . }} | |
| namespace: {{ default .Release.Namespace .Values.recommender.metrics.serviceMonitor.namespace | quote }} | |
| labels: | |
| {{- include "vertical-pod-autoscaler.recommender.labels" . | nindent 4 }} | |
| {{- if .Values.recommender.metrics.serviceMonitor.labels }} | |
| {{- include "common.tplvalues.render" ( dict "value" .Values.recommender.metrics.serviceMonitor.labels "context" $ ) | nindent 4 }} | |
| {{- end }} | |
| {{- if .Values.commonLabels }} | |
| {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | |
| {{- end }} | |
| {{- if or .Values.recommender.metrics.serviceMonitor.annotations .Values.commonAnnotations }} | |
| {{- $annotations := include "common.tplvalues.merge" ( dict "values" ( list .Values.recommender.metrics.serviceMonitor.annotations .Values.commonAnnotations ) "context" . ) }} | |
| annotations: {{- include "common.tplvalues.render" ( dict "value" $annotations "context" $ ) | nindent 4 }} | |
| {{- end }} | |
| {{ if .Values.recommender.metrics.serviceMonitor.enabled }} | |
| apiVersion: monitoring.coreos.com/v1 | |
| kind: ServiceMonitor | |
| metadata: | |
| name: {{ include "vertical-pod-autoscaler.recommender.fullname" . }} | |
| namespace: {{ default .Release.Namespace .Values.recommender.metrics.serviceMonitor.namespace | quote }} | |
| labels: | |
| {{- include "vertical-pod-autoscaler.recommender.labels" . | nindent 4 }} | |
| {{- if .Values.recommender.metrics.serviceMonitor.labels }} | |
| {{- include "common.tplvalues.render" ( dict "value" .Values.recommender.metrics.serviceMonitor.labels "context" $ ) | nindent 4 }} | |
| {{- end }} | |
| {{- if .Values.commonLabels }} | |
| {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | |
| {{- end }} | |
| {{- if or .Values.recommender.metrics.serviceMonitor.annotations .Values.commonAnnotations }} | |
| {{- $annotations := include "common.tplvalues.merge" ( dict "values" ( list .Values.recommender.metrics.serviceMonitor.annotations .Values.commonAnnotations ) "context" . ) }} | |
| annotations: {{- include "common.tplvalues.render" ( dict "value" $annotations "context" $ ) | nindent 4 }} | |
| {{- end }} |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
| {{- if .Values.admissionController.enabled }} | ||
| {{- if .Values.admissionController.serviceAccount.create -}} | ||
| apiVersion: v1 | ||
| kind: ServiceAccount | ||
| metadata: | ||
| name: {{ include "vertical-pod-autoscaler.admissionController.serviceAccountName" . }} | ||
| labels: | ||
| {{- include "vertical-pod-autoscaler.admissionController.labels" . | nindent 4 }} | ||
| {{- if .Values.commonLabels }} | ||
| {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | ||
| {{- end }} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix YAML Templating Errors in ServiceAccount Template
Similar to other YAML templates, an error on line 1 and indentation warnings on lines 10–11 have been detected. The conditional templating directives (e.g. {{- if … }}) are adversely affecting the YAML structure. Please revise these directives by removing unnecessary hyphens and adjusting the nindent values to ensure proper indentation.
A suggested diff for the labels block might look like:
- labels:
- {{- include "vertical-pod-autoscaler.admissionController.labels" . | nindent 4 }}
- {{- if .Values.commonLabels }}
- {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }}
- {{- end }}
+ labels:
+ {{ include "vertical-pod-autoscaler.admissionController.labels" . | nindent 2 }}
+ {{- if .Values.commonLabels }}
+ {{ include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }}
+ {{- end }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{- if .Values.admissionController.enabled }} | |
| {{- if .Values.admissionController.serviceAccount.create -}} | |
| apiVersion: v1 | |
| kind: ServiceAccount | |
| metadata: | |
| name: {{ include "vertical-pod-autoscaler.admissionController.serviceAccountName" . }} | |
| labels: | |
| {{- include "vertical-pod-autoscaler.admissionController.labels" . | nindent 4 }} | |
| {{- if .Values.commonLabels }} | |
| {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | |
| {{- end }} | |
| {{- if .Values.admissionController.enabled }} | |
| {{- if .Values.admissionController.serviceAccount.create -}} | |
| apiVersion: v1 | |
| kind: ServiceAccount | |
| metadata: | |
| name: {{ include "vertical-pod-autoscaler.admissionController.serviceAccountName" . }} | |
| labels: | |
| {{ include "vertical-pod-autoscaler.admissionController.labels" . | nindent 2 }} | |
| {{- if .Values.commonLabels }} | |
| {{ include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} | |
| {{- end }} |
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
| apiVersion: autoscaling.k8s.io/v1 | ||
| kind: VerticalPodAutoscaler | ||
| metadata: | ||
| name: vpa-vminsert | ||
| spec: | ||
| targetRef: | ||
| apiVersion: apps/v1 | ||
| kind: Deployment | ||
| name: vminsert-shortterm | ||
| updatePolicy: | ||
| updateMode: Auto | ||
| resourcePolicy: | ||
| containerPolicies: | ||
| - containerName: vminsert | ||
| minAllowed: | ||
| cpu: 250m | ||
| memory: 256Mi | ||
| maxAllowed: | ||
| cpu: 2000m | ||
| memory: 4Gi |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
VPA configuration for vminsert looks appropriate, but consider adding namespacing.
The VPA configuration for the vminsert component has reasonable resource boundaries, but doesn't specify a namespace.
🏁 Script executed:
#!/bin/bash
# Check if the targeted resources exist in the cluster/repo
# and verify if they're in the same namespace
echo "Checking for vminsert-shortterm deployment references"
fd --type f --extension yaml --extension yml "vminsert-shortterm" | xargs grep -l "vminsert-shortterm" | head -5Length of output: 227
Action: Add explicit namespace to the VPA configuration
The current YAML correctly configures resource boundaries and targets the vminsert-shortterm deployment, but it lacks an explicit namespace declaration. This could lead to the VPA being created in the default namespace even if the associated deployment resides elsewhere. Please verify the intended namespace for vminsert-shortterm and update the file accordingly.
- In packages/extra/monitoring/templates/vpa.yaml, under the
metadatasection, add:metadata: name: vpa-vminsert namespace: <your-namespace> # Replace <your-namespace> with the correct namespace
| resources: | ||
| {{- toYaml .Values.updater.resources | nindent 12 }} |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Ensure resource limits are set appropriately
Resource requests and limits are important for the VPA to function properly. Ensure that the default values in .Values.updater.resources are set to reasonable defaults for production use.
🏁 Script executed:
#!/bin/bash
# Check the default resource values in values.yaml
cat packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml | grep -A 15 "updater:" | grep -A 10 "resources:"Length of output: 134
Please run this script to verify whether the default resource settings under the updater section are defined and to check if they conform to the expected production defaults.
🏁 Script executed:
#!/bin/bash
# Print the entire file to inspect the "updater" section context in the values.yaml file.
echo "Full content of values.yaml (first 200 lines):"
head -n 200 packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml
echo ""
echo "Extracting updater section and any references to resources:"
awk '/updater:/ {flag=1} flag; /^$/ {flag=0}' packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml | grep -i "resources:" -C 3Length of output: 8023
Resource Defaults Missing for Updater
It appears that the deployment template references .Values.updater.resources in
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml
but our inspection of values.yaml did not reveal any default definitions for an updater. Without default resource requests and limits, the VPA's updater may not function correctly in production.
-
Action Needed: Add a dedicated
updatersection invalues.yamlwith default resource settings. For example:updater: resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi"
-
Recommendation: Verify that these defaults (or your chosen values) meet the production requirements for resource allocation.
| {{ include "common.redis.values.key.prefix" (dict "subchart" "true" "context" $) }} | ||
| Params: | ||
| - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false | ||
| */}} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Documentation has incorrect function name in usage example
The usage example in the documentation refers to common.redis.values.key.prefix but the actual function is named common.redis.values.keys.prefix.
Correct the function name in the documentation:
Usage:
-{{ include "common.redis.values.key.prefix" (dict "subchart" "true" "context" $) }}
+{{ include "common.redis.values.keys.prefix" (dict "subchart" "true" "context" $) }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{ include "common.redis.values.key.prefix" (dict "subchart" "true" "context" $) }} | |
| Params: | |
| - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false | |
| */}} | |
| {{ include "common.redis.values.keys.prefix" (dict "subchart" "true" "context" $) }} | |
| Params: | |
| - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false | |
| */}} |
| {{- define "common.redis.values.enabled" -}} | ||
| {{- if .subchart -}} | ||
| {{- printf "%v" .context.Values.redis.enabled -}} | ||
| {{- else -}} | ||
| {{- printf "%v" (not .context.Values.enabled) -}} | ||
| {{- end -}} | ||
| {{- end -}} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Function doesn't match documentation for subchart parameter
The common.redis.values.enabled function documentation indicates it accepts a parameter dictionary with context, but there's a mismatch between the documentation and implementation which also uses a subchart parameter.
Update the documentation to match the implementation:
{{/*
Auxiliary function to get the right value for enabled redis.
Usage:
-{{ include "common.redis.values.enabled" (dict "context" $) }}
+{{ include "common.redis.values.enabled" (dict "subchart" false "context" $) }}
+Params:
+ - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false
+ - context - Dict - Required. The context for the template evaluation.
*/}}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{- define "common.redis.values.enabled" -}} | |
| {{- if .subchart -}} | |
| {{- printf "%v" .context.Values.redis.enabled -}} | |
| {{- else -}} | |
| {{- printf "%v" (not .context.Values.enabled) -}} | |
| {{- end -}} | |
| {{- end -}} | |
| {{/* | |
| Auxiliary function to get the right value for enabled redis. | |
| Usage: | |
| {{ include "common.redis.values.enabled" (dict "subchart" false "context" $) }} | |
| Params: | |
| - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false | |
| - context - Dict - Required. The context for the template evaluation. | |
| */}} | |
| {{- define "common.redis.values.enabled" -}} | |
| {{- if .subchart -}} | |
| {{- printf "%v" .context.Values.redis.enabled -}} | |
| {{- else -}} | |
| {{- printf "%v" (not .context.Values.enabled) -}} | |
| {{- end -}} | |
| {{- end -}} |
| {{- define "common.secrets.exists" -}} | ||
| {{- $secret := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret) }} | ||
| {{- if $secret }} | ||
| {{- true -}} | ||
| {{- end -}} | ||
| {{- end -}} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Secret existence check function could be more explicit in its return value
The common.secrets.exists function returns "true" when a secret exists but returns nothing when it doesn't. A more consistent approach would be to return either "true" or "false".
Make the function return explicit boolean values in all cases:
{{- define "common.secrets.exists" -}}
{{- $secret := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret) }}
{{- if $secret }}
{{- true -}}
+ {{- else -}}
+ {{- false -}}
{{- end -}}
{{- end -}}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{- define "common.secrets.exists" -}} | |
| {{- $secret := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret) }} | |
| {{- if $secret }} | |
| {{- true -}} | |
| {{- end -}} | |
| {{- end -}} | |
| {{- define "common.secrets.exists" -}} | |
| {{- $secret := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret) }} | |
| {{- if $secret }} | |
| {{- true -}} | |
| {{- else -}} | |
| {{- false -}} | |
| {{- end -}} | |
| {{- end -}} |
527012c to
40aa65c
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (9)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrole.yaml (1)
7-10: 🛠️ Refactor suggestionFix Templating Indentation in Labels Section
The labels block usesnindent 4, which leads to indentation warnings (expected 2 spaces but found 4). Adjust the indentation—perhaps by usingnindent 2—to produce valid YAML structure.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/serviceaccount.yaml (2)
1-1: 🛠️ Refactor suggestionResolve YAML Syntax Issue at Template Start
The initial templating line ({{- if .Values.recommender.serviceAccount.create -}}) includes hyphens that may trigger a YAMLlint error. Consider removing the hyphens or modifying the directive format to ensure the YAML parser receives proper node content.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
7-10: 🛠️ Refactor suggestionCorrect Indentation in Labels and Common Labels Blocks
The use ofnindent 4in the labels section causes indentation warnings (expected 2 spaces). Reducing the indent level (for example, tonindent 2) will help maintain consistency with YAML formatting rules.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/job.yaml (2)
1-1: 🛠️ Refactor suggestionResolve YAML Templating Syntax Error at File Start
The file begins with a templating statement ({{- if .Values.crds.enabled }}) that uses a leading hyphen, potentially causing YAMLlint syntax errors. Consider removing the hyphen to ensure valid YAML parsing.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
7-10: 🛠️ Refactor suggestionFix Indentation in Label Blocks
Within the labels section, the use ofnindent 4is resulting in an indentation mismatch (expected an indent of 2 spaces). Updating the indentation (for example, tonindent 2) would align the output with YAML standards.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/metrics-service.yaml (1)
6-9: 🛠️ Refactor suggestionAddress Templating and Indentation Issues in Labels Section
The templating function on line 6 ({{- include "vertical-pod-autoscaler.recommender.labels" . | nindent 4 }}) produces a syntax error and the subsequent indentation (lines 7–9) does not meet YAML expectations (expected 2 spaces instead of 4). Consider removing the hyphen from the opening delimiter and adjusting the nindent value (e.g. tonindent 2) so that the output YAML is correctly formatted.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/tls-secret.yaml (2)
1-1: 🛠️ Refactor suggestionResolve YAML Templating Syntax at File Start
The opening templating line ({{- if .Values.admissionController.enabled }}) employs hyphens that may lead to a YAMLlint syntax error. Removing the hyphen (i.e. using{{ if .Values.admissionController.enabled }}) can resolve this issue.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
13-14: 🛠️ Refactor suggestionCorrect Indentation in Common Labels Block
The use ofnindent 4for rendering.Values.commonLabelsis causing indentation warnings (expected 2 spaces but found 4). Adjusting the indentation level (for example, usingnindent 2) will help maintain valid and consistent YAML structure.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 13-13: wrong indentation: expected 2 but found 4
(indentation)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/values.yaml (1)
10-22: 🛠️ Refactor suggestionRecommender ExtraArgs & Hardcoded Prometheus Address
Therecommender.extraArgsblock is set up well; however, theprometheus-addressvalue is currently hardcoded (line 21). This replicates concerns noted in previous reviews regarding portability across environments. Consider parameterizing this value—for example, by using a default value expression—to improve flexibility.
🧹 Nitpick comments (73)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_errors.tpl (1)
22-24: Consider updating the documentation URL.The error message references a Bitnami documentation URL, but this appears to be for a Kubernetes Vertical Pod Autoscaler chart. If this template was borrowed from Bitnami's common library, consider updating the URL to point to your own documentation or the official VPA documentation.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_warnings.tpl (2)
26-45: Consider adding validation for chart annotations.The function assumes that
.context.Chart.Annotations.imageswill always exist. Consider adding a validation check before accessing this field to prevent potential errors when annotations are missing or empty.{{- define "common.warnings.modifiedImages" -}} {{- $affectedImages := list -}} {{- $printMessage := false -}} - {{- $originalImages := .context.Chart.Annotations.images -}} + {{- $originalImages := default "" .context.Chart.Annotations.images -}} {{- range .images -}}
59-108: Well-structured resources validation with comprehensive edge case handling.The resources validation function handles multiple scenarios effectively:
- Root-level resources
- Section-level resources with appropriate exclusions for disabled components
- Nested path traversal with proper error avoidance
The warning message is clear and includes a helpful link to Kubernetes documentation.
However, there's a minor inconsistency in warning message formatting compared to other warnings (one uses "WARNING:" prefix, another uses emoji). Consider standardizing the format across all warning messages for consistency.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_images.tpl (3)
11-26: Consider a fallback for missing or empty repository values.If
.imageRoot.repositoryis potentially empty, the resulting image string could be incomplete. Ensure that.imageRoot.repositoryis never empty or implement a fallback logic to gracefully handle that scenario.
28-59: Remove or consolidate the deprecated pullSecrets function to reduce duplication.This function is marked deprecated, yet it's introduced alongside the more robust
common.images.renderPullSecrets. Consider removing or unifying them to avoid confusion and duplication.
95-109: Correct typographical error and consider fallback for AppVersion.Line 96 has a minor misspelling ("ingores" → "ignores"). Also, if
.chart.AppVersionis missing or empty, this logic may yield an empty version. You could add a fallback or error handling.-Return the proper image version (ingores image revision/prerelease info & fallbacks to chart appVersion) +Return the proper image version (ignores image revision/prerelease info & falls back to chart appVersion)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml (1)
1-1: Address YAMLlint False PositiveYAMLlint reports an error at line 1 due to the templating syntax (the
-after{{). This is a common false positive when linting Helm templates. Consider adding a linter directive at the top of the file (or configuring your linter) to ignore templating directives in order to avoid such warnings. For example, you might add:+ # yamllint disable-lineabove line 1 if your linting tools support inline disable comments.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_redis.tpl (1)
68-72: Documentation is missing parameter informationThe usage example for
common.redis.values.standarized.versiondoesn't show all required parameters. The function usescommon.redis.values.keys.prefixinternally, which requires the subchart parameter.Update the usage example to include the subchart parameter:
Usage: -{{ include "common.redis.values.standarized.version" (dict "context" $) }} +{{ include "common.redis.values.standarized.version" (dict "subchart" false "context" $) }} +Params: + - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false + - context - Dict - Required. The context for the template evaluation.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mysql.tpl (2)
68-69: Documentation is missing parameter informationThe usage example for
common.mysql.values.enableddoesn't include the subchart parameter, but the function implementation uses it.Update the documentation to include the subchart parameter:
Usage: -{{ include "common.mysql.values.enabled" (dict "context" $) }} +{{ include "common.mysql.values.enabled" (dict "subchart" false "context" $) }} +Params: + - subchart - Boolean - Optional. Whether MySQL is used as subchart or not. Default: false + - context - Dict - Required. The context for the template evaluation.
52-53: Documentation is missing parameter informationThe usage example for
common.mysql.values.auth.existingSecretdoesn't include the subchart parameter, but the function implementation uses it.Update the documentation to include the subchart parameter:
Usage: -{{ include "common.mysql.values.auth.existingSecret" (dict "context" $) }} +{{ include "common.mysql.values.auth.existingSecret" (dict "subchart" false "context" $) }}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mariadb.tpl (3)
13-13: Fix copy-paste error in documentationThe documentation mentions "mysql-passwords-secret" instead of "mariadb-passwords-secret", which appears to be a copy-paste error.
- - secret - String - Required. Name of the secret where MariaDB values are stored, e.g: "mysql-passwords-secret" + - secret - String - Required. Name of the secret where MariaDB values are stored, e.g: "mariadb-passwords-secret"
68-69: Documentation is missing parameter informationThe usage example for
common.mariadb.values.enableddoesn't include the subchart parameter, but the function implementation uses it.Update the documentation to include the subchart parameter:
Usage: -{{ include "common.mariadb.values.enabled" (dict "context" $) }} +{{ include "common.mariadb.values.enabled" (dict "subchart" false "context" $) }} +Params: + - subchart - Boolean - Optional. Whether MariaDB is used as subchart or not. Default: false + - context - Dict - Required. The context for the template evaluation.
52-53: Documentation is missing parameter informationThe usage example for
common.mariadb.values.auth.existingSecretdoesn't include the subchart parameter, but the function implementation uses it.Update the documentation to include the subchart parameter:
Usage: -{{ include "common.mariadb.values.auth.existingSecret" (dict "context" $) }} +{{ include "common.mariadb.values.auth.existingSecret" (dict "subchart" false "context" $) }}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mongodb.tpl (1)
30-31: Consider using built-in Helm checks for empty values instead of string matching
Currently, the condition checks if$existingSecretisnilor an empty string by comparing against\"\". For better readability and future-proofing, consider using Helm functions likehasKeyor checking for an empty string viadefaultexpansions to avoid confusion about string quotes.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_postgresql.tpl (1)
20-20: Improve variable naming for the replication password key
The variable$valueKeyPostgresqlReplicationEnabledsuggests a boolean but actually holds the key name for the replication password. Consider renaming it to$valueKeyPostgresqlReplicationPasswordfor clarity.- {{- $valueKeyPostgresqlReplicationEnabled := include "common.postgresql.values.key.replicationPassword" . -}} + {{- $valueKeyPostgresqlReplicationPassword := include "common.postgresql.values.key.replicationPassword" . -}}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_utils.tpl (1)
57-67: Selecting the first defined key
Reversing the list and picking the first non-empty item can be tricky to reason about. Ensure callers realize this picks the last item in the user-provided list that is non-empty.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_affinities.tpl (4)
41-51: Consider adding default behavior for the node affinity type.The template handles 'soft' and 'hard' types but has no default behavior or error handling for invalid types.
{{- define "common.affinities.nodes" -}} {{- if eq .type "soft" }} {{- include "common.affinities.nodes.soft" . -}} {{- else if eq .type "hard" }} {{- include "common.affinities.nodes.hard" . -}} + {{- else }} + {{- include "common.affinities.nodes.soft" . -}} + {{- /* Default to soft affinity if type is unspecified or invalid */ -}} {{- end -}} {{- end -}}
61-95: Inconsistent indentation in component label formatting.The component label is directly printed without using
nindentlike the custom labels, which could cause formatting inconsistencies.{{- if not (empty $component) }} - {{ printf "app.kubernetes.io/component: %s" $component }} + app.kubernetes.io/component: {{ $component }} {{- end }}
97-127: Inconsistent indentation in component label formatting.Similar to the soft affinity template, the component label printing could be improved for consistency.
{{- if not (empty $component) }} - {{ printf "app.kubernetes.io/component: %s" $component }} + app.kubernetes.io/component: {{ $component }} {{- end }}
129-139: Documentation doesn't match implementation and missing default behavior.The example in the documentation doesn't match the actual parameters required, and there's no default behavior for invalid types.
{{/* Return a podAffinity/podAntiAffinity definition -{{ include "common.affinities.pods" (dict "type" "soft" "key" "FOO" "values" (list "BAR" "BAZ")) -}} +{{ include "common.affinities.pods" (dict "type" "soft" "component" "FOO" "customLabels" .Values.podLabels "context" $) -}} */}} {{- define "common.affinities.pods" -}} {{- if eq .type "soft" }} {{- include "common.affinities.pods.soft" . -}} {{- else if eq .type "hard" }} {{- include "common.affinities.pods.hard" . -}} + {{- else }} + {{- include "common.affinities.pods.soft" . -}} + {{- /* Default to soft affinity if type is unspecified or invalid */ -}} {{- end -}} {{- end -}}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md (6)
1-7: Heading Formatting and Punctuation:
The title and introductory headers are clear. However, the “TL;DR;” heading on line 7 ends with a semicolon, which can conflict with markdown style guidelines (MD026). Consider removing the trailing semicolon for a cleaner heading.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
7-7: Trailing punctuation in heading
Punctuation: ';'(MD026, no-trailing-punctuation)
35-44: Superlative Correction in Upgrading Instructions:
In line 43 the phrase “with the most latest release” is used. To adhere to standard English usage, please change it to “with the latest release.”-The command upgrades the existing `my-release` deployment with the most latest release of the chart. +The command upgrades the existing `my-release` deployment with the latest release of the chart.🧰 Tools
🪛 LanguageTool
[grammar] ~43-~43: Only “latest” (without ‘most’) is used to write the superlative.
Context: ...istingmy-releasedeployment with the most latest release of the chart. TIP: Use `he...(MOST_SUPERLATIVE)
🪛 markdownlint-cli2 (0.17.2)
40-40: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
47-53: Grammar Improvement in Version Upgrade Notes:
In line 53 the sentence “Information about services are no more injected into pod's environment variable.” has a verb–subject agreement issue and could be made clearer. Consider rephrasing it to:
“Information about services is no longer injected into the pod's environment variables.”-Information about services are no more injected into pod's environment variable. +Information about services is no longer injected into the pod's environment variables.🧰 Tools
🪛 LanguageTool
[uncategorized] ~53-~53: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...caler-1.3.0 Information about services are no more injected into pod's environment...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~53-~53: You might be missing the article “the” here.
Context: ...bout services are no more injected into pod's environment variable. ### Upgrading ...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
🪛 markdownlint-cli2 (0.17.2)
51-51: Bare URL used
null(MD034, no-bare-urls)
61-68: Improving Repetitive Bullet Point Structure:
The “Upgrading to version 8.0.0” section (lines 61–68) lists several parameter renamings with very similar wording. While the information is clear, consider varying the sentence structure slightly in the bullet points to enhance readability.🧰 Tools
🪛 LanguageTool
[style] ~67-~67: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ender.metrics.service.ports.metrics. - Parameterupdater.metrics.service.port` has been...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
69-75: Minor Article Insertion for Clarity:
In the “Upgrading to version 7.0.0” section (line 74), the bullet point forimagePullSecretscould read more naturally with a slight rewording. For example,
“ParameterimagePullSecretshas been renamed toglobal.imagePullSecrets.”
This small change improves clarity.-Parameter `imagePullSecrets` has been renamed `global.imagePullSecrets`. +Parameter `imagePullSecrets` has been renamed to `global.imagePullSecrets`.🧰 Tools
🪛 LanguageTool
[uncategorized] ~74-~74: You might be missing the article “the” here.
Context: ...s now configured inimage.registry. - ParameterimagePullSecretshas been renamed `gl...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
87-91: Clarifying Pre-Installation Terminology:
In the “Upgrading to version 4.0.0” section (line 91), the phrase “pre-install/pre-upgrade job” might be unclear as a noun phrase. Consider replacing it with “a pre-installation/pre-upgrade job” to improve clarity and correctness.-Custom resource definitions are now created and upgraded with a pre-install/pre-upgrade job. +Custom resource definitions are now created and upgraded with a pre-installation/pre-upgrade job.🧰 Tools
🪛 LanguageTool
[grammar] ~91-~91: The word ‘pre-install’ is not a noun.
Context: ...ons are now created and upgraded with a pre-install/pre-upgrade job. ### Upgrading to vers...(A_INSTALL)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md (4)
44-71: ImageRoot YAML Formatting ConsistencyThe ImageRoot section defines individual parameters (registry, repository, tag, pullPolicy, pullSecrets, debug) with their descriptions. To enhance readability and maintain consistent styling, consider consolidating these definitions into a single fenced YAML code block rather than splitting the block for the registry parameter and then listing subsequent keys outside of a code block.
141-173: Example of Use: Grammatical CorrectionsThe example use case is very informative; however, there are minor grammatical issues that could be refined for clarity. For example, in the sentence on line 143, consider changing:
-When we store sensitive data for a deployment in a secret, some times we want to give to users the possibility of using theirs existing secrets. +When we store sensitive data for a deployment in a secret, sometimes we want to give users the possibility of using their existing secrets.This change improves readability and grammatical precision.
186-197: Alert Example PunctuationFor enhanced clarity in the alert example, consider adding a comma to the sentence. For instance, change:
-If we force those values to be empty we will see some alerts +If we force those values to be empty, we will see some alerts.A slight punctuation improvement like this helps the reader process the information more smoothly.
199-246: Upgrading Section ClarityThe Upgrading section is comprehensive and provides clear instructions on transitioning to version 1.0.0, including detailed upgrade considerations and useful links. To further enhance clarity, consider rephrasing the upgrade considerations (especially around lines 215–219) to reduce repetitive phrasing. For example, differentiating the upgrade path for Helm v3 from the unsupported Helm v2 might benefit from a slightly varied narrative.
🧰 Tools
🪛 LanguageTool
[style] ~212-~212: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... you shouldn't face any issues - If you want to upgrade to this version using Helm v2, ...(REP_WANT_TO_VB)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrole.yaml (2)
1-1: Helm templating false positive on YAMLlint error.
The error on line 1 ({{- if .Values.crds.enabled }}) is a known false positive from YAML lint tools when parsing Helm template syntax.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
9-10: Indentation warning in the commonLabels block.
YAMLlint reports an indentation warning on lines 9–10 (expected 2 spaces but found 4). Verify that the use ofnindent 4produces the intended output in the rendered YAML. If the output is correct, you may safely ignore this warning or adjust your linter configuration.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml (2)
1-1: Helm templating false positive on YAMLlint error.
The use of Helm templating tags (e.g.,{{- if .Values.crds.enabled }}) might trigger a YAMLlint error on line 1. Ensure your YAML linter is configured to understand Helm templates.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
9-10: Indentation warning in the commonLabels block.
YAMLlint flags potential indentation issues on lines 9 and 10. Please verify that thenindent 4usage achieves the desired indentation in your final YAML output.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/pdb.yaml (2)
1-1: Helm templating false positive on YAMLlint error.
Line 1’s templating tag ({{- if .Values.admissionController.enabled }}) may be misinterpreted by YAMLlint. Confirm that your linter is set to process Helm templates correctly.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
10-11: Indentation warning in the commonLabels block.
YAMLlint indicates that lines 10–11 might be indented more than expected. Double-check that usingnindent 4here produces the YAML structure you require after template rendering.🧰 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)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrolebinding.yaml (2)
1-1: Helm templating false positive on YAMLlint error.
The templating syntax on line 1 is causing a YAMLlint error; this is a known false positive when working with Helm charts. Adjust your linter settings if necessary.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
9-10: Indentation warning in the commonLabels block.
YAMLlint reports that lines 9–10 have an unexpected indentation level. Verify thatnindent 4produces the desired structure in the final YAML output and modify if needed.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml (2)
1-1: Helm templating false positive on YAMLlint error.
The templating syntax at line 1 ({{- if .Values.recommender.pdb.create }}) might trigger a YAMLlint error. This is a common false positive in Helm chart files; ensure your linter is modified to handle these cases.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
9-10: Indentation warning in the commonLabels block.
YAMLlint warns about incorrect indentation at lines 9–10 (expected 2 spaces but found 4). Confirm that usingnindent 4here achieves the output you expect in the final rendered YAML.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml (2)
1-4: Helm Templating Validity:
The templating on lines 1–4 (e.g.{{- if .Values.updater.enabled }}and{{- if .Values.updater.metrics.serviceMonitor.enabled }}) is standard for Helm charts. The YAMLlint error on line 1 (expected node content but found '-') is a common false positive due to Helm’s templating syntax. Please verify the rendered output usinghelm templateto ensure valid YAML.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
10-15: Dynamic Label & Annotation Indentation:
The metadata block uses dynamic templated labels and conditionally rendered annotations (lines 10–15). YAMLlint warns about unexpected indentation; however, this is frequently a false positive when using Helm templating. Confirm viahelm templatethat the final YAML indentation meets Kubernetes standards.🧰 Tools
🪛 YAMLlint (1.35.1)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml (2)
1-2: Helm Conditional Rendering for ServiceAccount:
The condition on line 1 ({{- if .Values.crds.enabled }}) is correctly gating the creation of this ServiceAccount. The YAMLlint error here is due to Helm templating and should be verified by rendering the chart.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
6-10: Metadata and Label Inclusion:
The metadata section properly builds the resource name and dynamically includes labels. Although YAMLlint reports indentation warnings on lines 9–10, these are typically benign within a Helm template context.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml (1)
1-4: Conditional Rendering for Admission Controller Monitoring:
The conditions on lines 1–2 using{{- if .Values.admissionController.enabled }}and{{- if .Values.admissionController.metrics.serviceMonitor.enabled }}correctly gate the creation of the ServiceMonitor. The leading dash in the templating may trigger YAMLlint errors, but these are understood false positives in a Helm context.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml (2)
1-3: Conditional Creation of Updater ServiceAccount:
The nested conditions ({{- if .Values.updater.enabled }}and{{- if .Values.updater.serviceAccount.create -}}) ensure that the ServiceAccount is only created when desired. The YAMLlint error on line 1 is a false positive due to templating syntax—please verify usinghelm template.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
4-11: Metadata and Label Handling:
The metadata block correctly sets the service account name and labels, and conditionally includes common labels. The warnings about indentation on lines 10–11 should be rechecked in the rendered output.🧰 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)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml (2)
1-3: Conditional Definition of ClusterRoleBinding:
The ClusterRoleBinding is conditionally rendered based on.Values.admissionController.enabled. The YAMLlint error on line 1 is attributable to templating syntax and is not a cause for concern if the rendered YAML is correct.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
4-13: Metadata and Label Customization:
The metadata section, which dynamically includes labels and annotations based on common values, is well implemented. YAMLlint indentation warnings (notably on lines 9–10) should be verified post-render; they are usually false positives in Helm templates.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml (2)
7-11: Metadata Labels Indentation CheckYAMLlint is flagging that the labels block (lines 7–11) is indented deeper than expected. Please verify that the use of
nindent 4is intentional and that the final rendered YAML meets your formatting expectations. If not, consider adjusting to a lower indent (for example,nindent 2). For instance:- {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 4 }} + {{- include "common.tplvalues.render" ( dict "value" .Values.commonLabels "context" $ ) | nindent 2 }}🧰 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)
12-14: Annotations Block Indentation WarningSimilar indentation remarks apply to the annotations section. Ensure that the use of
{{- ... }}andnindent 4here produces valid YAML. A quick review of the rendered output is advised.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml (2)
5-9: Metadata Labels Indentation in ConfigMapYAMLlint warnings suggest that the labels block (lines 5–9) may be over-indented (expected 2 spaces instead of 4). Please verify the intended formatting and adjust the
nindentparameters if needed.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
10-14: Annotations Block Indentation in ConfigMapIndentation for the annotations block (lines 10–14) is also triggering warnings. Confirm that the current template directives render valid YAML or consider revising the indent settings.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/servicemonitor.yaml (1)
1-1: ServiceMonitor Conditional RenderingThe initial conditional (
{{- if .Values.recommender.metrics.serviceMonitor.enabled }}) is clear. Note that leading hyphens may trigger YAMLlint errors; please double-check the rendered result.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml (1)
1-10: Helm Templating & Conditional Metadata Rendering
The conditional check ({{- if .Values.crds.enabled }}) and use of helper templates (for the ConfigMap name and labels) are implemented correctly. Note that YAMLlint errors—especially the “syntax error: expected the node content, but found '-'” and indentation warnings on these templating lines—are common false positives when linting Helm templates.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml (1)
1-12: ClusterRole Metadata & Templated Labels
The metadata block for the ClusterRole uses dynamic templating to generate the API version, name, labels, and annotations. Although YAMLlint reports indentation issues on lines 6–9 (and an error on line 6), these are likely false positives stemming from Helm’s templating syntax. It is recommended to render the template to verify that the final YAML is correctly indented.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/pod.yaml (1)
1-37: LGTM! Test pod correctly configured for vertical-pod-autoscaler testing.The test pod is well-structured with appropriate Helm templating. It uses a combination of built-in template functions and conditional rendering for labels and annotations. The container mounts both the test ConfigMap and the admission-controller TLS secret correctly.
I suggest adding resource limits to the test container to prevent potential resource consumption issues during testing.
containers: - name: tests image: {{ include "common.images.image" ( dict "imageRoot" .Values.tests.image "global" .Values.global ) }} imagePullPolicy: {{ .Values.tests.image.pullPolicy }} + resources: + limits: + cpu: 100m + memory: 128Mi + requests: + cpu: 50m + memory: 64Mi volumeMounts:🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml (2)
1-10: Templating and YAMLlint Warnings
The use of templating directives (e.g.{{- if .Values.updater.enabled }}and the use ofnindent) may trigger YAML lint errors such as "expected the node content" or indentation warnings (notably on lines 9–10). Please verify that when the template is rendered, the output YAML maintains the correct structure and indentation.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-13: Annotations Block – Verify Indentation
The optional annotations block (lines 11–13) merges values from.Values.commonAnnotations. Double-check that the rendered YAML output preserves proper indentation when these values are present.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml (3)
1-10: General Templating and Conditional Rendering
The deployment template begins with a condition on.Values.updater.enabledand then renders metadata (name, labels, etc.). While the templating is clear, be mindful that YAML linting tools may complain about the templated syntax. Ensure that after rendering, the YAML structure meets Kubernetes’ requirements.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-14: Annotations Merging for Deployment Metadata
The merging ofupdater.deploymentAnnotationswithcommonAnnotationsis handled via thecommon.tplvalues.mergehelper. It would be good to confirm that the merged annotations output renders as a valid YAML map when supplied in the final deployment.
122-124: Resource Configuration Verification
The container’s resource section (lines 122–124) uses.Values.updater.resources. Please ensure that default resource requests and limits are defined in yourvalues.yamlso that the updater container always has valid resource settings.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml (2)
1-10: YAML Templating and Linting Considerations
Similar to other templated files, the conditional block and use ofnindent(lines 1–10) may lead to YAMLlint warnings concerning indentation and node content. Verify that the final rendered Service manifest has proper structure and indentation.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-14: Merged Annotations for Metrics Service
The annotations merging logic (lines 11–14) is implemented to combine updater-specific and common annotations. Please double-check that the resulting annotations map is correctly formatted in the final Service YAML.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml (4)
1-10: Admission Controller Deployment – Conditional Rendering
The deployment is conditionally rendered based on.Values.admissionController.enabled. Ensure that your Helm values correctly toggle this deployment. Overall, the metadata (name, labels, etc.) appears appropriately templated.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-14: Annotations Merging in Admission Controller Metadata
The annotations block (lines 11–14) merges deployment-specific annotations with common ones. Verify that, in the rendered output, the resultant annotations are valid YAML and reflect the intended configuration.
30-33: TLS Checksum Annotation for Rolling Updates
The block that conditionally adds a TLS secret checksum (lines 30–33) is a useful mechanism to trigger pod rollouts on secret updates. Confirm that the file path (/admission-controller/tls-secret.yaml) and the hash computation (usingsha256sum) meet your security and operational expectations.
46-49: Host Network Configuration
The conditional configuration for host networking (lines 46–49) setsdnsPolicyandhostNetworkwhen enabled. Review whether enabling host networking aligns with your security model and network policies in production.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml (3)
1-10: CRD Metadata Templating and Indentation
The metadata section in the CRD uses templating for labels and annotations. Static analysis warnings (e.g. at line 6 regarding a syntax error and lines 7–9 for indentation) are likely false positives inherent to Helm templating. Ensure the final rendered CRD validates against Kubernetes’ API (using, for example,kubectl apply --dry-run=server).🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
43-70: CRD v1 Schema and Printer Columns
The v1 version schema (lines 43–70 and subsequent sections) is comprehensive and includes several additionalPrinterColumns. It is important to keep these definitions updated with any future changes to the VerticalPodAutoscaler spec.
1-371: Overall CRD Definition Review
The CRD forVerticalPodAutoscaleris detailed and supports both v1 and v1beta2 formats. It covers metadata, versioning, schema definitions, and status information. Ensure that integration tests validate the CRD creation and that conversions between versions work as expected.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml (2)
328-620: Recommender Section is Consistent and ModularThe recommender configuration mirrors many aspects of the admission controller settings:
- It includes a similar layout for image configurations, pod disruption budgets, service account, probes, and resource configurations.
- Inline comments provide clarity over each parameter’s intent.
One opportunity for improvement is to consider reducing repetition—since the probe definitions (liveness, readiness, startup) appear with identical properties in both the admission controller and recommender sections.
Suggestion (using YAML anchors):
If your Helm chart and YAML parser support anchors/aliases, you might define a default probe configuration once and reference it in each section. For example:+# Define a common probe configuration for reuse +defaultProbe: &defaultProbe + enabled: true + initialDelaySeconds: 0 + periodSeconds: 10 + timeoutSeconds: 1 + failureThreshold: 3 + successThreshold: 1Then replace, for instance, the liveness probe in the admission controller with:
-livenessProbe: - enabled: true - initialDelaySeconds: 0 - periodSeconds: 10 - timeoutSeconds: 1 - failureThreshold: 3 - successThreshold: 1 +livenessProbe: *defaultProbeThis approach would DRY up the file and make future updates easier.
620-883: Updater Section is Detailed and Mirrors Other ComponentsThe updater section closely follows the structural pattern of the previous components:
- Configuration for image details, pod disruption budgets, service accounts, and health probes are consistently applied.
- Many values for resource requests and limits are left commented to serve as guidance, which is a common practice in Helm charts.
No critical issues are identified here. As before, consider whether the repetitive probe and resource configurations could be centralized with YAML anchors if it fits your project’s maintainability goals.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/Chart.lockis excluded by!**/*.lock
📒 Files selected for processing (79)
packages/core/platform/bundles/paas-full.yaml(1 hunks)packages/core/platform/bundles/paas-hosted.yaml(1 hunks)packages/extra/monitoring/Chart.yaml(1 hunks)packages/extra/monitoring/templates/vpa.yaml(1 hunks)packages/extra/versions_map(1 hunks)packages/system/vertical-pod-autoscaler/Chart.yaml(1 hunks)packages/system/vertical-pod-autoscaler/Makefile(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/.helmignore(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/Chart.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/LICENSE(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/.helmignore(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/Chart.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_affinities.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_capabilities.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_compatibility.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_errors.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_images.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_ingress.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_labels.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_names.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_resources.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_secrets.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_storage.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_tplvalues.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_utils.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_warnings.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_cassandra.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mariadb.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mongodb.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mysql.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_postgresql.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_redis.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_validations.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/ci/default-values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/NOTES.txt(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/metrics-service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/pdb.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/tls-secret.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/job.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/metrics-service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/servicemonitor.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/pod.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/_helpers.tpl(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrolebinding.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml(1 hunks)packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/values.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (27)
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/.helmignore
- packages/extra/monitoring/Chart.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_storage.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/ci/default-values.yaml
- packages/system/vertical-pod-autoscaler/Chart.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/NOTES.txt
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/Chart.yaml
- packages/core/platform/bundles/paas-hosted.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/values.yaml
- packages/core/platform/bundles/paas-full.yaml
- packages/system/vertical-pod-autoscaler/Makefile
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_resources.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/LICENSE
- packages/extra/versions_map
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_labels.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_validations.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/.helmignore
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/_helpers.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/_helpers.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/_helpers.tpl
- packages/extra/monitoring/templates/vpa.yaml
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_secrets.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/_helpers.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/_helpers.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/_helpers.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_tplvalues.tpl
- packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/Chart.yaml
🧰 Additional context used
🪛 YAMLlint (1.35.1)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/metrics-service.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrole.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrole.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/deployment.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/metrics-service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/pdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/tls-secret.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 13-13: wrong indentation: expected 2 but found 4
(indentation)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrole.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/clusterrolebinding.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/job.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrolebinding.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/pdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/servicemonitor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/pod.yaml
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/clusterrolebinding.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
[warning] 11-11: wrong indentation: expected 2 but found 4
(indentation)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
🪛 LanguageTool
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md
[grammar] ~43-~43: Only “latest” (without ‘most’) is used to write the superlative.
Context: ...isting my-release deployment with the most latest release of the chart. TIP: Use `he...
(MOST_SUPERLATIVE)
[uncategorized] ~53-~53: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...caler-1.3.0 Information about services are no more injected into pod's environment...
(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~53-~53: You might be missing the article “the” here.
Context: ...bout services are no more injected into pod's environment variable. ### Upgrading ...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[style] ~67-~67: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ender.metrics.service.ports.metrics. - Parameter updater.metrics.service.port` has been...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~74-~74: You might be missing the article “the” here.
Context: ...s now configured in image.registry. - Parameter imagePullSecrets has been renamed `gl...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[grammar] ~91-~91: The word ‘pre-install’ is not a noun.
Context: ...ons are now created and upgraded with a pre-install/pre-upgrade job. ### Upgrading to vers...
(A_INSTALL)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md
[uncategorized] ~140-~140: Did you mean the adverb “sometimes” (= occasionally)?
Context: ...tive data for a deployment in a secret, some times we want to give to users the possibilit...
(SOME_TIMES)
[uncategorized] ~184-~184: Possible missing comma found.
Context: ... }} If we force those values to be empty we will see some alerts console hel...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~212-~212: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... you shouldn't face any issues - If you want to upgrade to this version using Helm v2, ...
(REP_WANT_TO_VB)
🪛 markdownlint-cli2 (0.17.2)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md
7-7: Trailing punctuation in heading
Punctuation: ';'
(MD026, no-trailing-punctuation)
10-10: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
11-11: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
29-29: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
30-30: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
40-40: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
51-51: Bare URL used
null
(MD034, no-bare-urls)
108-108: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
118-118: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
126-126: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
127-127: Dollar signs used before commands without showing output
null
(MD014, commands-show-output)
🔇 Additional comments (104)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_names.tpl (1)
1-71: Well-structured naming template with Kubernetes naming constraints properly handled.The template file implements a comprehensive set of naming functions that follow Helm best practices by:
- Properly handling name truncation to 63 characters (Kubernetes DNS naming limitation)
- Providing name overrides via Values
- Handling name collision cases
- Supporting dependency naming and namespace overrides
- Including clear documentation for each function
These functions will provide consistent naming across the vertical-pod-autoscaler chart resources, making the chart more maintainable and compliant with Kubernetes naming requirements.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_errors.tpl (2)
1-28: Well-structured Helm template for password validation during upgrades.This template file provides a clean implementation of error handling for empty passwords during chart upgrades. The implementation follows Helm best practices with clear documentation, proper error messaging, and correct usage of Helm template functions.
10-17: Documentation is clear and comprehensive.The usage example and parameter documentation are well-written, making it easy for developers to understand how to use this template function correctly.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_warnings.tpl (3)
14-17: Good implementation of the rolling tag warning check.The detection logic for rolling tags is well-implemented, using both the repository check and regex pattern to identify potentially problematic image tags. The warning message with documentation link is helpful for users.
38-43: Security warning is informative and provides specific details.The warning effectively communicates the security and performance risks of image substitution while providing actionable information by listing the specific affected images.
80-97: Robust conditional logic for detecting relevant resource sections.The template properly avoids flagging resource sections for components that are disabled or have zero replicas, which prevents unnecessary warnings and focuses attention on active components that need resource definitions.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_images.tpl (2)
1-5: Use license references consistently.These lines follow the APACHE-2.0 license header consistently. No concerns here.
61-93: Good use of templating in renderPullSecrets.This function properly consolidates pull secrets while allowing template evaluation. The approach is flexible and addresses diverse use cases.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/extra-list.yaml (1)
1-4: Template Loop and Include Usage Looks GoodThe template correctly iterates over
.Values.extraDeployand renders the deployment configuration using thecommon.tplvalues.renderhelper. The use of the{{-and{{delimiters is appropriate for whitespace control in Helm templates.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_cassandra.tpl (1)
1-78: Implementation looks good and well-documented.The template functions for validating Cassandra passwords are well-structured with clear documentation, proper error handling, and consistent implementation. The validation logic correctly checks for existing secrets and handles both subchart and standalone configurations appropriately.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_redis.tpl (2)
59-62: Documentation has incorrect function name in usage exampleThe usage example in the documentation refers to
common.redis.values.key.prefixbut the actual function is namedcommon.redis.values.keys.prefix.Correct the function name in the documentation:
Usage: -{{ include "common.redis.values.key.prefix" (dict "subchart" "true" "context" $) }} +{{ include "common.redis.values.keys.prefix" (dict "subchart" "true" "context" $) }}
47-53: Function doesn't match documentation for subchart parameterThe
common.redis.values.enabledfunction documentation indicates it accepts a parameter dictionary with context, but there's a mismatch between the documentation and implementation which also uses a subchart parameter.Update the documentation to match the implementation:
{{/* Auxiliary function to get the right value for enabled redis. Usage: -{{ include "common.redis.values.enabled" (dict "context" $) }} +{{ include "common.redis.values.enabled" (dict "subchart" false "context" $) }} +Params: + - subchart - Boolean - Optional. Whether redis is used as subchart or not. Default: false + - context - Dict - Required. The context for the template evaluation. */}}packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_mongodb.tpl (2)
75-79: Clarify the negation logic for 'enabled'
Whensubchartis false, the code uses(not .context.Values.enabled). This might invert the expected behavior, causing unexpected activation of MongoDB. Double-check that this is intentional or align the logic more intuitively.
83-97: Validate usage of “auth” prefix
The functioncommon.mongodb.values.key.authappropriately prefixes keys; however, ensure that references in chart values files align exactly (e.g.,mongodb.auth) to avoid mismatched key paths.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/validations/_postgresql.tpl (1)
74-79: Confirm the negation for top-level 'enabled'
Similar to the MongoDB validations, using(not .context.Values.enabled)may accidentally invert the expected outcome. If the parent chart’senabledis false, this code forcibly enables PostgreSQL. Ensure this behavior is intended.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_capabilities.tpl (19)
1-5: Header documentation and licensing
Looks good. The license information and headers are properly stated, and no issues are apparent.
11-13: Confirm property resolution order for kubeVersion
This logic uses nesteddefaultto set priority among.Values.global.kubeVersion,.Values.kubeVersion, and.Capabilities.KubeVersion.Version. Ensure the intended precedence is correct and consistent with your design (i.e., validating that.Values.global.kubeVersionindeed takes priority). Otherwise, consider reversing the arguments.
18-26: Validate version threshold for PodDisruptionBudget
The threshold<1.21-0for selectingpolicy/v1beta1is correct for older clusters, but be mindful that 1.21 eventually graduated it topolicy/v1. Looks fine overall.
30-38: NetworkPolicy API version check
The switch fromextensions/v1beta1tonetworking.k8s.io/v1is standard. This define block is correctly handling version differences.
42-50: CronJob API version consideration
batch/v1beta1for<1.21-0andbatch/v1otherwise is appropriate given the CronJob graduation timeline.
54-62: DaemonSet API version check
Extensions toapps/v1logic is consistent with typical Helm versioning checks.
66-74: Deployment API version check
Consistently mirrors the transition fromextensions/v1beta1toapps/v1. No issues found.
78-86: StatefulSet API version
Again aligns with older vs. newer Kubernetes versions. Implementation is consistent with Helm best practices.
90-102: Ingress API version fallback
It's a nice approach letting.Values.ingress.apiVersionoverride. The fallback fromextensions/v1beta1tonetworking.k8s.io/v1for older versions is correct.
106-114: RBAC resource version check
Moving fromv1beta1tov1for<1.17is valid. Looks good.
118-126: CRD version logic
apiextensions.k8s.io/v1beta1for<1.19, otherwisev1. This check is standard for CRD usage.
130-138: APIService version check
Switching toapiregistration.k8s.io/v1for newer clusters is correct.
142-154: Horizontal Pod Autoscaler version check
Splitting intoautoscaling/v2beta1orautoscaling/v2beta2for older clusters and defaulting tov2for ≥1.23 is appropriate.
158-170: Vertical Pod Autoscaler version check
This parallel logic for the VPA is consistent with the HPA block. The approach is sound.
174-180: PodSecurityPolicy support
Detecting support based on<1.25-0is correct since PSP was removed in 1.25.
184-190: AdmissionConfiguration support
The logic for enabling it on ≥1.23 is well aligned with its stable rollout.
194-203: AdmissionConfiguration API version
Transitions throughapiserver.config.k8s.io/v1alpha1,v1beta1, andv1are precisely targeted for the documented versions.
208-218: PodSecurityConfiguration API version
The version checks for <1.23 (alpha), <1.25 (beta), and ≥1.25 (v1) exactly reflect the Pod Security Admission progress.
225-229: Check for Helm versioning
Using regex matching to detect Helm 3.3+ is a known pattern to avoid “interface not found” errors on older Helm. This is a reliable approach.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_utils.tpl (4)
12-15: Exporting a secret value with kubectl
This is a neat utility for retrieving and exporting the secret data. Confirm that your environment always has kubectl available and that you handle any potential errors from “secret not found.”
22-31: Field-to-env-var conversion
The transformation to uppercase with underscores is straightforward. The logic is correct, and usage is clear.
38-50: Recursive value key retrieval
Fails early if any part of the key path is missing, which is helpful for debugging misconfigurations. This approach is robust.
69-78: Checksum generation
Omitting metadata fields and then computing the SHA256 is a good technique for reloading pods only on relevant changes. This looks optimal.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_compatibility.tpl (2)
13-17: Platform detection for Openshift
Using.Capabilities.APIVersions.Has "security.openshift.io/v1"as an indicator is the standard approach for identifying OpenShift. No issues here.
24-43: Dynamic security context adaptation
This function cleverly removes user/group settings in forced or auto-detected OpenShift scenarios to avoid restricted-v1 SCC conflicts. Also skipping fields when privileged is enabled is appropriate.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_affinities.tpl (4)
1-7: LGTM - Well-structured header with proper licensing information.The copyright header and vim configuration are correctly set up with the appropriate SPDX license identifier.
8-23: LGTM - Properly implemented soft node affinity template.The
common.affinities.nodes.softtemplate correctly implements preferredDuringSchedulingIgnoredDuringExecution for node affinity with proper indentation and parameter handling.
25-39: LGTM - Properly implemented hard node affinity template.The
common.affinities.nodes.hardtemplate correctly implements requiredDuringSchedulingIgnoredDuringExecution for node affinity with appropriate nodeSelectorTerms structure.
53-59: LGTM - Good default topology key implementation.The template provides a sensible default value of "kubernetes.io/hostname" for the topology key if not specified.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/README.md (2)
9-13: Concise Quick Start Section:
The TL;DR code block (lines 9–13) provides clear, quick installation instructions. This section is succinct and effectively demonstrates how to add the Helm repository and deploy the chart.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
10-10: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
11-11: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
14-459: Overall Documentation Quality:
The remainder of the document—from the Introduction and Prerequisites (lines 14–23) through the detailed upgrade history, configuration tables, installation examples, limitations, and licensing—is comprehensive and well structured. The tables and code examples are informative, and the content covers all the essential aspects for deploying and customizing the Vertical Pod Autoscaler via Helm. Please review the minor grammatical and stylistic suggestions above, and then the documentation is in excellent shape.🧰 Tools
🪛 LanguageTool
[grammar] ~43-~43: Only “latest” (without ‘most’) is used to write the superlative.
Context: ...istingmy-releasedeployment with the most latest release of the chart. TIP: Use `he...(MOST_SUPERLATIVE)
[uncategorized] ~53-~53: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...caler-1.3.0 Information about services are no more injected into pod's environment...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~53-~53: You might be missing the article “the” here.
Context: ...bout services are no more injected into pod's environment variable. ### Upgrading ...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[style] ~67-~67: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ender.metrics.service.ports.metrics. - Parameterupdater.metrics.service.port` has been...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~74-~74: You might be missing the article “the” here.
Context: ...s now configured inimage.registry. - ParameterimagePullSecretshas been renamed `gl...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[grammar] ~91-~91: The word ‘pre-install’ is not a noun.
Context: ...ons are now created and upgraded with a pre-install/pre-upgrade job. ### Upgrading to vers...(A_INSTALL)
🪛 markdownlint-cli2 (0.17.2)
29-29: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
30-30: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
40-40: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
51-51: Bare URL used
null(MD034, no-bare-urls)
108-108: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
118-118: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
126-126: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
127-127: Dollar signs used before commands without showing output
null(MD014, commands-show-output)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/README.md (11)
1-4: Title and Introduction ClarityThe title and introductory description effectively communicate that this is a Bitnami Helm Library Chart. The heading is clear and immediately informs the reader about the purpose of the document.
5-12: TL;DR Section CompletenessThe TL;DR section is well-structured and provides a concise YAML snippet for dependencies. Ensure that the version format (e.g., "2.x.x") meets your documented release strategy.
14-16: Helpful Command ExampleThe console snippet for running
helm dependency updateis a useful quick-start guide for users setting up dependencies.
18-25: ConfigMap YAML Example ClarityThe YAML snippet for the ConfigMap is clear and demonstrates the expected templating (e.g., using
{{ include "common.names.fullname" . }}).
27-27: Production Advisory NoteThe note encouraging the use of VMware Tanzu Application Catalog is informative. It might be worthwhile to periodically verify that external links remain accessible and up-to-date.
29-34: Introduction Section ClarityThe overview provided in the introduction succinctly explains how this chart will support new chart development using Helm. The explanation is straightforward and helpful.
35-40: Prerequisites SectionThe prerequisites are clearly listed, ensuring users know the minimum requirements (Kubernetes 1.23+ and Helm 3.8.0+).
72-79: Example Instance SectionThe “An instance would be:” section clearly demonstrates an example of the ImageRoot configuration. The sample values are easy to follow.
87-121: Persistence YAML SchemaThe Persistence section provides a comprehensive YAML schema with clear descriptions and examples (including notes about disabling dynamic provisioning). This section is well laid out and informative.
123-139: ExistingSecret YAML SchemaThe ExistingSecret section concisely outlines the expected structure for an existing Kubernetes secret. The example provided is clear, making it easy for users to replicate or customize the schema.
175-184: ValidateValue ConfigurationThe ValidateValue snippet, complete with the dict constructions and the include statement, is well-formed and demonstrates the intended validation logic effectively.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~184-~184: Possible missing comma found.
Context: ... }}If we force those values to be empty we will see some alertsconsole hel...(AI_HYDRA_LEO_MISSING_COMMA)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/servicemonitor.yaml (1)
24-41: Endpoint Configuration Review:
Theendpointssection is well structured with conditionally inserted properties (e.g.interval,scrapeTimeout,honorLabels,metricRelabelings, andrelabelings). Ensure that these values correctly render based on provided Helm values.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/serviceaccount.yaml (1)
11-16: Annotations Merge Handling:
The annotations block (lines 11–16) merges Helm hook annotations with any provided common annotations. This approach is clean and effective—just ensure the merge function outputs the expected structure.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/servicemonitor.yaml (2)
5-16: Metadata & Label Configuration:
This metadata section dynamically renders names, labels, and annotations for the admission controller’s ServiceMonitor. YAMLlint’s indentation warnings (lines 11–15) can typically be disregarded if the rendered YAML is valid; however, it is worth confirming viahelm template.🧰 Tools
🪛 YAMLlint (1.35.1)
[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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
[warning] 15-15: wrong indentation: expected 2 but found 4
(indentation)
20-41: ServiceMonitor Spec and Endpoint Setup:
The spec section (lines 20–41) correctly configures the ServiceMonitor’s options, including conditional fields likejobLabeland multiple endpoint parameters. The structure appears sound and aligns with common monitoring setups.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/serviceaccount.yaml (1)
12-15: Merged Annotations for ServiceAccount:
Annotations are merged from updater-specific and common annotations via templating. This concise approach is effective; please validate that the merged output meets deployment requirements.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrolebinding.yaml (2)
14-18: Role Reference Consistency:
TheroleRefblock (lines 14–18) clearly defines the ClusterRole references using templated values. Confirm that the template functions return the expected role identifiers for proper RBAC configuration.
19-22: Subjects Configuration Check:
The subjects section (lines 19–22) specifies the ServiceAccount that the ClusterRoleBinding applies to. This configuration is straightforward and correct; ensure the namespace and service account name are rendered appropriately.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/pdb.yaml (3)
1-2: Conditional Rendering is ClearThe nested conditions for rendering the PDB based on both
updater.enabledandupdater.pdb.createare clear and correctly applied.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
15-21: PDB Spec Section VerificationThe spec block—including conditional inclusion of
minAvailableandmaxUnavailableand the selector block—is implemented correctly. Confirm that the selector labels (usingnindent 6) render as intended.
25-26: Closing Conditional BlocksThe closing directives properly end the conditional blocks. Ensure that no extra whitespace or misalignments are introduced in the final rendered YAML.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/tests/configmap.yaml (1)
16-45: Embedded Python Test Script VerificationThe Python test script embedded in the ConfigMap appears well structured and self-contained. Ensure that these tests (which check connectivity to various services) successfully run in your monitoring environment.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrolebinding.yaml (3)
5-12: YAML Templating Indentation in MetadataYAMLlint reports indentation issues in the labels and annotations block. This issue is similar to prior feedback; please recheck the use of leading hyphens and
nindentvalues to ensure proper YAML structure.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
13-16: RoleRef Configuration is CorrectThe
roleRefsection (lines 13–16) is dynamically generated and correctly specifies the ClusterRole. No issues detected here.
17-20: Subjects Block ValidationThe subject binding for the ServiceAccount (lines 17–20) is clearly defined and appears correct. Good job ensuring that the namespace is quoted.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/servicemonitor.yaml (3)
7-14: Metadata Labels Indentation in ServiceMonitorWarnings indicate that the labels block (lines 7–14) has indentation levels that might not match YAML expectations. Review the
nindent 4usage here, similar to other templates.🧰 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)
[warning] 14-14: wrong indentation: expected 2 but found 4
(indentation)
15-18: Annotations Block in ServiceMonitorThe annotations block (lines 15–18), which conditionally merges annotations, should be rechecked for correct indentation. This is a common pitfall with YAML templating.
19-47: ServiceMonitor Specification OverviewThe spec section—with conditional jobLabel, endpoints (along with interval, scrapeTimeout, honorLabels, and relabeling configurations), namespaceSelector, and the selector—is comprehensive. Confirm that the final rendered output aligns with your monitoring setup.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/serviceaccount.yaml (4)
1-2: ServiceAccount Conditional RenderingThe conditional blocks on lines 1–2 effectively ensure that the ServiceAccount is created only when both
admissionController.enabledandserviceAccount.createare true.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
7-11: ServiceAccount Labels IndentationYAMLlint has flagged potential indentation issues in the labels block (lines 7–11). This is similar to earlier templates; please verify if adjusting the
nindentvalue (or modifying hyphen usage) leads to valid YAML.🧰 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)
12-15: Annotations Merge and Rendering in ServiceAccountThe annotations are merged and rendered on lines 12–15. The logic is sound—just ensure that the templating does not disrupt the required YAML structure.
16-17: Closing Conditionals for ServiceAccountThe closing directives (lines 16–17) correctly conclude the conditional blocks. Verify that no extraneous whitespace or unwanted tokens are rendered.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/clusterrole.yaml (1)
1-1:Details
❓ Verification inconclusive
Resolve YAML Templating Syntax Error at File Start
The leading templating directive ({{- if .Values.admissionController.enabled }}) uses a hyphen that can cause YAMLlint to report a syntax error. Consider removing the hyphen (e.g. switching to{{ if .Values.admissionController.enabled }}) or adjusting the placement to ensure proper YAML content is parsed.
Attention: Verify Helm Template Linting Behavior
The file begins with the Helm templating directive:
{{- if .Values.admissionController.enabled }}The leading hyphen is intentionally used to trim whitespace—a common pattern in Helm charts. Although some YAML linters may report a syntax error due to the hyphen, this is typically a false positive if the linter isn’t configured to recognize Helm templating.
- Verify your YAML linter settings to ensure it properly processes Helm templates.
- If lint errors persist despite the correct configuration, you might consider switching to:
but be mindful that this change could affect whitespace and the resulting YAML formatting.{{ if .Values.admissionController.enabled }}🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/crds/configmap.yaml (2)
11-16: Annotations Block is Clean and Flexible
The annotations section correctly embeds Helm hooks (pre-install,pre-upgrade) and conditionally includes common annotations if provided. This strategy allows for flexible deployment configurations.
17-21: Dynamic Data Section for CRD Files
The use of therangeover.Files.Glob "files/crds/*"along with rendering file contents viatplis an effective approach to populate the ConfigMap data. This design keeps the CRD definitions modular and maintainable.packages/system/vertical-pod-autoscaler/values.yaml (3)
1-9: Updater Resources Configuration
The configuration for theupdatersection (resource limits and requests) is clear and follows expected conventions. The memory and CPU allocations appear consistent.
23-29: Recommender Resources Block
The resource limits and requests for therecommenderare well defined. The allocations for CPU and memory are consistent with the component’s needs.
30-37: AdmissionController Resources Block
TheadmissionControllerresources section is straightforward, setting proper limits and requests. No issues noted here.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/metrics-service.yaml (4)
1-10: Metrics Service Metadata & Conditional Labels
The conditional rendering based on.Values.admissionController.enabledand the dynamic inclusion of labels and (optional) common labels are implemented properly. As before, static analysis warnings on indentation should be considered false positives due to Helm templating syntax.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-14: Annotations Handling for Metrics Service
The block that conditionally merges and renders annotations is neat and flexible. It allows combining annotations from both the service configuration and common global annotations.
15-25: Service Specification with Conditional Networking Options
The spec section is well structured. It conditionally includes networking options such asclusterIP,ipFamilyPolicy, andipFamiliesbased on the values provided. This flexibility accommodates various cluster networking setups.
26-33: Ports and Selector Configuration
The service correctly defines the port (with a targetPort alias ofhttp-metrics) and sets the selector using a helper template. The implementation is clean and effective.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/admission-controller/service.yaml (4)
1-10: Admission Controller Service Metadata & Labels
The service for the admission controller (vpa-webhook) uses fixed naming but dynamic labels. The structure is consistent with Helm best practices. Again, YAMLlint warnings regarding the templating markers are expected false positives.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[warning] 10-10: wrong indentation: expected 2 but found 4
(indentation)
11-14: Dynamic Annotations for the Service
The annotations block is conditionally rendered by merging service-specific annotations with any globally defined common annotations. This approach maintains configurability without redundancy.
15-31: Service Spec: Flexible Networking & Session Affinity Options
The spec section effectively configures the service type and conditionally includes properties such asclusterIP,ipFamilyPolicy, and session affinity settings (sessionAffinity,sessionAffinityConfig). This design supports a range of deployment scenarios.
32-39: Ports and Selector are Configured Appropriately
The ports (using HTTPS with a target port aliashttps) and selector settings leverage helper templates to ensure consistency. The implementation meets expected service configuration standards.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/clusterrole.yaml (1)
13-150: Comprehensive RBAC Rules for the Recommender Component
The RBAC rules within this ClusterRole are extensive and cover permissions for metrics access, pod/node management, event handling, and leader election via leases. The rules correctly target multiple API groups and resources, which should equip the recommender with all necessary permissions. It would be prudent to double-check that the API groups (e.g.,"poc.autoscaling.k8s.io","autoscaling.k8s.io") align with the current cluster requirements and CRD versions.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalercheckpoints.yaml (1)
1-229: Well-structured CRD for VerticalPodAutoscalerCheckpointThe CRD definition is comprehensive and follows Kubernetes best practices. It properly supports both v1 (active) and v1beta2 (inactive) API versions, which provides a clear path for version transitions. The detailed schema includes all necessary fields for maintaining VPA state, with appropriate types and descriptions.
The API approval annotation
api-approved.kubernetes.ioconfirms this is an approved Kubernetes API extension.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/charts/common/templates/_ingress.tpl (1)
1-74: Well-documented ingress helper functionsThe template file defines four well-documented helper functions for ingress configurations that handle different Kubernetes API versions appropriately:
common.ingress.backend- Generates compatible backend entries based on API versioncommon.ingress.supportsPathType- Checks pathType field supportcommon.ingress.supportsIngressClassname- Checks ingressClassname field supportcommon.ingress.certManagerRequest- Validates cert-manager annotationsEach function includes clear usage instructions and parameter details, following Helm best practices.
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/recommender/deployment.yaml (1)
1-141: Comprehensively configured recommender deploymentThe deployment manifest for the VPA recommender includes all necessary configurations:
- Proper use of security contexts at both pod and container levels
- Well-configured health checks with customizable probes
- Flexible resource management
- Support for environment variables from multiple sources
- Comprehensive scheduling controls (affinity, tolerations, topology spread)
The deployment template follows Helm best practices with conditional inclusion of optional features and proper templating.
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 7-7: wrong indentation: expected 2 but found 4
(indentation)
[warning] 8-8: wrong indentation: expected 2 but found 4
(indentation)
[warning] 9-9: wrong indentation: expected 2 but found 4
(indentation)
[error] 6-6: syntax error: expected the node content, but found '-'
(syntax)
packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/templates/updater/metrics-service.yaml (1)
17-19: Conditional ClusterIP Configuration
The block (lines 17–19) conditionally sets theclusterIPfield for a ClusterIP service. Confirm that this condition accurately reflects your intended configuration and that the final rendered YAML is valid when.Values.updater.metrics.service.clusterIPis provided.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/files/crds/verticalpodautoscalers.yaml (1)
371-376: Deprecation and Support for v1beta2
The CRD includes a deprecated v1beta2 version along with a deprecation warning message (lines 371–376). This is good practice. Be sure your users are informed about the deprecation and that the transition to v1 is well communicated in your documentation.packages/system/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/values.yaml (6)
1-4: Header and File Description are ClearThe initial comments make it evident that this file provides default YAML values for the vertical pod autoscaler. The file-level documentation is concise and follows a standard format.
5-13: Global Parameters Section Looks AppropriateThe
globalsection correctly defines the Docker image registry and pull secrets. Using an empty string forimageRegistryand an empty array forimagePullSecretsis common practice to force users to override these defaults.
14-32: Common Parameters Section is Well-DocumentedThe common parameters (e.g.,
kubeVersion,nameOverride,fullnameOverride, etc.) are clearly defined with inline comments that explain their purpose. This makes it easier for users to understand how to override defaults if needed.
34-327: Admission Controller Configuration is ComprehensiveThis section defines a rich set of configuration options for the admission controller, including:
- Image settings (registry, repository, tag, pullPolicy)
- Pod Disruption Budget (PDB) with an explicit
minAvailableand a commented-outmaxUnavailablevalue (which gives flexibility but may benefit from a default if one is expected)- Service account configurations and pod-level settings such as security contexts and host aliases
- Detailed probe configurations (liveness, readiness, and startup probes) that follow a consistent structure
- TLS settings with auto-generation hints
Overall, the section is thorough. Consider whether the commented-out values (e.g., for
maxUnavailable,clusterIP, or probe overrides in TLS and priorityClassName) should be activated by default or remain commented for user override.
884-949: CRDs Configuration is Minimal but ClearThe CRDs section is brief:
- It enables CRDs and points to an image (
bitnami/kubectl) with a specific tag (1.29.3).- Make sure the chosen image and version align with your cluster’s requirements and are tested with your installation process.
- The additional pod annotations, labels, and security contexts are also provided for consistency.
If this image is used solely to apply CRDs, verify that the version is appropriate and remains secure over time.
949-967: Tests Configuration Provides a Simple BaselineThe
testssection is succinct, defining an image registry, repository, tag, and pull policy:
- This minimal configuration is useful as a placeholder for integrating tests.
- If more elaborate testing configurations become necessary, consider expanding this section or providing additional descriptive comments.
Overall, it meets the purpose for the current release.
| {{- $valueKeyPostgresqlPassword := include "common.postgresql.values.key.postgressPassword" . -}} | ||
| {{- $valueKeyPostgresqlReplicationEnabled := include "common.postgresql.values.key.replicationPassword" . -}} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Rename “postgressPassword” to “postgresPassword”
The function name and references use “postgress,” which appears to be a typo. Renaming consistently to “postgresPassword” can prevent confusion and reflect standard naming.
- {{- $valueKeyPostgresqlPassword := include "common.postgresql.values.key.postgressPassword" . -}}
+ {{- $valueKeyPostgresqlPassword := include "common.postgresql.values.key.postgresPassword" . -}}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| {{- $valueKeyPostgresqlPassword := include "common.postgresql.values.key.postgressPassword" . -}} | |
| {{- $valueKeyPostgresqlReplicationEnabled := include "common.postgresql.values.key.replicationPassword" . -}} | |
| {{- $valueKeyPostgresqlPassword := include "common.postgresql.values.key.postgresPassword" . -}} | |
| {{- $valueKeyPostgresqlReplicationEnabled := include "common.postgresql.values.key.replicationPassword" . -}} |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
packages/system/monitoring-agents/charts/fluent-bit/templates/tests/test-connection.yaml (1)
20-20: Enhance Delay Flexibility with Configurable Delay ParameterAdding a
sleep 5sbefore thewgetcommand is a practical enhancement to ensure thefluent-bitservice has adequate time to start up. To improve flexibility across different environments, consider parameterizing the delay duration (e.g., via a value in.Values.testFramework.delay), so it can be adjusted without modifying the template.packages/core/installer/values.yaml (1)
1-3: Confirm Intentional Downgrade & Repository ChangeThe Docker image reference has been updated from the previous image hosted on
ghcr.io/aenix-io/cozystackand with versionv0.27.0to a new repository (kklinch0/cozystack) with an image tag of0.26.1.0along with a new SHA256 digest. Please confirm that this downgrade in version—as well as the change in image repository—is intentional and that it aligns with the requirements of the new VPA monitoring feature. Additionally, ensure that any documentation or release notes are updated to reflect this change.packages/system/monitoring-agents/charts/fluent-bit/ci/ci-values.yaml (1)
22-32: Lua Scripts Section:
Introducing theluaScriptsblock provides useful examples for custom log filtering. The templating infilter_with_templating_example.lua(using{{ .Values.logLevel | quote }}) adds dynamic flexibility. Ensure that your CI/CD or deployment pipeline correctly renders these templates to avoid runtime errors.packages/system/monitoring-agents/charts/kube-state-metrics/values.yaml (1)
163-169: Introduce environment variables block for kube-state-metricsA new
env: {}block has been added to allow for custom environment variable injection. The commented sample provides clear guidance on potential usage. Consider updating the chart documentation to highlight this new configuration option.packages/system/vertical-pod-autoscaler/values.yaml (1)
30-36: Consider adjusting memory request for admission controllerThere's a significant gap between the memory limit (256Mi) and request (50Mi) for the admission controller. While this allows for more efficient resource utilization, it could potentially lead to pod evictions if memory usage spikes unexpectedly.
Consider setting the memory request to at least 30% of the limit:
admissionController: resources: limits: memory: 256Mi requests: cpu: 50m - memory: 50Mi + memory: 80Mipackages/system/monitoring-agents/charts/kube-state-metrics/templates/deployment.yaml (2)
69-76: Consistent Handling of Environment Variables
There are now two conditional blocks for injecting environment variables depending on whether autosharding is enabled. This ensures that theenvvalues provided in.Values.envare rendered with the proper indentation in both scenarios. Consider unifying the logic in the future to reduce duplication if possible.
326-332: Flexible Affinity Configuration Handling
The affinity configuration now checks whether.Values.affinityis a map and usestoYamlaccordingly; otherwise, it processes the value as a template withtpl. This added flexibility enables more dynamic configuration. Consider adding a brief note in the documentation to explain when to use each form.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (37)
packages/core/installer/values.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/Chart.yaml(2 hunks)packages/system/monitoring-agents/charts/fluent-bit/README.md(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/ci/ci-values.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/NOTES.txt(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/_pod.tpl(2 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/configmap-luascripts.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/psp.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/scc.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/tests/test-connection.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/vpa.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/values.yaml(5 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/Chart.yaml(2 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/templates/deployment.yaml(5 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/templates/role.yaml(1 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/values.yaml(4 hunks)packages/system/monitoring-agents/charts/metrics-server/RELEASE.md(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/.helmignore(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/Chart.yaml(2 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/README.md(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/common-labels-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/default-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/networkpolicy-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/pod-labels-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/port-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/service-labels-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/serviceport-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/NOTES.txt(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/_helpers.tpl(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/daemonset.yaml(4 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/psp-clusterrole.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/rbac-configmap.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/serviceaccount.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/servicemonitor.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/values.yaml(8 hunks)packages/system/monitoring-agents/values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/values.yaml(1 hunks)
💤 Files with no reviewable changes (7)
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/default-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/common-labels-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/networkpolicy-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/service-labels-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/port-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/serviceport-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/pod-labels-values.yaml
✅ Files skipped from review due to trivial changes (10)
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/NOTES.txt
- packages/system/monitoring-agents/charts/metrics-server/RELEASE.md
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/psp-clusterrole.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/serviceaccount.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/.helmignore
- packages/system/monitoring-agents/charts/fluent-bit/templates/NOTES.txt
- packages/system/monitoring-agents/charts/prometheus-node-exporter/README.md
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/rbac-configmap.yaml
- packages/system/monitoring-agents/charts/fluent-bit/templates/vpa.yaml
- packages/system/monitoring-agents/charts/fluent-bit/README.md
🔇 Additional comments (37)
packages/system/monitoring-agents/charts/fluent-bit/templates/configmap-luascripts.yaml (1)
11-11: Dynamic Template Evaluation Usingtpl:
The change on line 11 now processes each Lua script value with thetplfunction before quoting it, which enables dynamic template evaluation within the ConfigMap. This enhances flexibility by allowing the incorporation of runtime context in Lua script values.Please ensure that any data in
.Values.luaScriptsis properly sanitized or validated, especially if it can be influenced by external input, to avoid unintended code execution or template injection vulnerabilities.packages/system/monitoring-agents/charts/fluent-bit/templates/_pod.tpl (2)
111-113: Enhanced hot reload flexibility with extra watch volumes supportThe addition of support for
extraWatchVolumesis a good enhancement that allows the Fluent Bit reloader to monitor additional configuration volumes beyond the default ones. This aligns well with the vertical pod autoscaler integration, giving users more flexibility in their monitoring setup.Also applies to: 119-122
142-142: Minor whitespace correctionAdded a trailing space after
-luascriptsfor consistent formatting.packages/system/monitoring-agents/charts/fluent-bit/templates/scc.yaml (2)
27-30: Dynamic Configuration for runAsUser:
Switching from a static configuration to a dynamic one using thewith,toYaml, andnindenthelpers now allows flexible specification via.Values.openShift.securityContextConstraints.runAsUser. This enhancement is valuable as it lets operators supply tailored values at deployment. Please verify that the values provided from your Helm values maintain the correct YAML structure and that omission (when not provided) results in valid output.
31-34: Dynamic Templating for seLinuxContext:
Similarly, replacing the staticseLinuxContextwith a dynamic output viatoYamlenhances the template’s flexibility. Ensure that.Values.openShift.securityContextConstraints.seLinuxContextoutputs a valid YAML fragment in all intended scenarios and that it preserves the strict security policies required.packages/system/monitoring-agents/charts/fluent-bit/ci/ci-values.yaml (4)
6-11: Extra Volume Mounts Definition:
The newextraVolumeMountsblock is well defined—each mount has a clearnameandmountPath. This addition enhances the pod's configurability by allowing extra directories to be mounted, which is especially useful for flexible log routing or configuration overrides.
12-17: Extra Volumes Configuration:
This section successfully pairs with the volume mounts by declaring the correspondingextraVolumesusingemptyDir: {}. While this approach is appropriate for ephemeral storage, please verify that it aligns with your production persistence requirements.
33-38: Output Configuration for Fluent Bit:
Theconfig.outputsblock directs logs to standard output, which is a common and useful default for containerized environments. If more complex logging requirements arise, consider whether additional output plugins or configurations might be necessary.
39-43: Hot Reload Configuration:
EnablinghotReloadwithextraWatchVolumesis a smart move to allow dynamic reloading of configuration when files in the extra volumes change. It would be good to verify that this mechanism works reliably across your deployment scenarios.packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/servicemonitor.yaml (1)
19-22: Flexible targetLabels configuration addedThe new block uses a
withdirective andtoYamlto conditionally render atargetLabelssection when provided. This expands user configuration for ServiceMonitor labels. Please double-check that the indentation aligns with adjacent sections (e.g. thepodTargetLabelsblock) so that the rendered YAML remains valid.packages/system/monitoring-agents/values.yaml (1)
31-33: New extraArgs for kube-state-metrics addedThe addition of the
extraArgsfield with the argument
--metric-labels-allowlist=pods=[*],deployments=[*]
enhances the configurability for kube-state-metrics, allowing administrators to specify which label sources are allowed. The syntax and indentation look correct.packages/system/monitoring-agents/charts/fluent-bit/Chart.yaml (3)
4-4: Updated OCI image description in annotationThe updated annotation now clearly communicates that the Fluent Bit OCI image has been updated to v3.2.8. This improves traceability of the chart modifications.
6-7: appVersion updated to 3.2.8The
appVersionfield has been updated accordingly, ensuring consistency with the new OCI image version. Make sure that any related documentation or CI configurations are aligned with this update.
27-27: Chart version bumped to 0.48.9The chart version bump reflects the underlying changes. Ensuring that users and automation tools see the version change helps maintain clear versioning and upgrade paths.
packages/system/monitoring-agents/charts/kube-state-metrics/values.yaml (1)
107-109: Update kubeRBACProxy image tag to v0.18.2Updating the kubeRBACProxy image tag to
v0.18.2is a good move for incorporating security and functionality improvements. This change is consistent with similar updates in related charts.packages/system/monitoring-agents/charts/fluent-bit/templates/psp.yaml (1)
23-30: Dynamic PodSecurityPolicy configuration for runAsUser and seLinuxRefactoring the PodSecurityPolicy to render
runAsUserandseLinuxsettings dynamically via values improves flexibility and security. UsingtoYamlwithnindent 4should ensure proper alignment in the output YAML. Please verify that the rendered configuration meets your security requirements.packages/system/vertical-pod-autoscaler/values.yaml (3)
1-8: Resource configuration for updater component looks appropriateThe resource configuration for the VPA updater component sets appropriate limits and requests based on expected usage patterns.
10-22: Hardcoded Prometheus address may not be portable across environmentsThe prometheus-address value is hardcoded to a specific environment URL. This may cause issues when deploying to different environments.
Consider parameterizing this value to make it configurable:
recommender: extraArgs: storage: prometheus - prometheus-address: http://vmselect-shortterm.tenant-root.svc.cozy.local:8481/select/0/prometheus/ + prometheus-address: {{ .Values.recommender.prometheusAddress | default "http://vmselect-shortterm.tenant-root.svc.cozy.local:8481/select/0/prometheus/" }} prometheus-cadvisor-job-name: cadvisor
23-28: Resource configuration for recommender component looks appropriateThe resource configuration for the VPA recommender component sets appropriate limits and requests based on expected usage patterns.
packages/system/monitoring-agents/charts/kube-state-metrics/templates/role.yaml (1)
108-131:Details
✅ Verification successful
RBAC permissions for additional resources look good
The added permissions follow the existing pattern in the role template and correctly use conditional inclusion based on the collectors configuration. These new permissions will allow kube-state-metrics to monitor ingressclasses, clusterrolebindings, clusterroles, and roles when enabled in the collectors list.
🏁 Script executed:
#!/bin/bash # Description: Verify that the collectors for the newly added resources are properly defined in values.yaml # Check if the collectors for the new resources are defined in values.yaml echo "Checking collectors configuration in values.yaml..." rg -A 1 "collectors:" packages/system/monitoring-agents/charts/kube-state-metrics/values.yamlLength of output: 249
RBAC additions look correctly implemented – please note the conditional behavior
The new RBAC resource blocks for ingressclasses, clusterrolebindings, clusterroles, and roles are implemented following the established pattern. They will be activated only if their corresponding keys are explicitly added to the collectors list in the values file. Our verification shows that the default configuration in
values.yamlcurrently includes onlycertificatesigningrequests, so the new permissions won’t be enabled by default. If you intend for these additional permissions to be active, be sure to updatevalues.yamlaccordingly.packages/system/monitoring-agents/charts/kube-state-metrics/Chart.yaml (1)
7-7:Details
✅ Verification successful
Version updates and maintainer URLs are correctly configured
The chart has been updated to use kube-state-metrics 2.15.0 and chart version 5.30.1. Maintainer GitHub URLs have been added, which improves documentation and follows best practices.
Also applies to: 18-18, 21-21, 24-24, 29-29
🌐 Web query:
What's new in kube-state-metrics 2.15.0 compared to earlier versions?💡 Result:
kube-state-metrics v2.15.0 introduces several notable improvements and changes compared to earlier versions, focusing on enhanced metrics, stability, and security. Here are the key updates:
Core Enhancements
- Golang v1.23.5 and k8s.io/client-go v0.32.1 support for improved performance and Kubernetes API compatibility[8]
- Added read/write timeouts for HTTP requests to prevent long-running scrapes from causing instability[8]
New Metrics & Features
- Job Monitoring
kube_job_status_suspendedmetric to track suspended Jobs[8]- Service Insights
kube_service_infonow includesexternal_traffic_policylabel for tracking service traffic distribution[8]- StatefulSet Improvements
kube_statefulset_ordinals_startpromoted from alpha to stable status[8]- CronJob Timezone Support
kube_cronjob_next_schedule_timebecomes timezone-aware for accurate scheduling calculations[8]
Critical Fixes
Issue Type Resolution Memory Management Fixed big memory value overflow in large clusters[8] CRD Handling Resolved panic in custom resource metric generation[8] Sharding Improved DaemonSet pod selection logic for unscheduled pods[8] Security Deduplicated tolerations before metric creation to prevent data leaks[8]
Architectural Changes
- Automatic memory limit detection for better resource management[8]
- Concurrent metric storage using sync.Map for improved performance under load[8]
- Deprecated endpoint address metrics (
kube_endpoint_address_available,kube_endpoint_address_not_ready) fully removed[4]
Operational Improvements
# New health check endpoints in deployment specs[13] livenessProbe: path: /livez readinessProbe: path: /readyz
- Added dedicated
/livezand/readyzendpoints for Kubernetes-native health checks[13]- Enhanced security context defaults with stricter seccomp profiles and non-root execution[13]
For clusters upgrading from versions before 2.10, note these cumulative changes since v2.0:
- Horizontal Pod Autoscaler metrics renamed (
kube_hpa_*→kube_horizontalpodautoscaler_*)[1]- Label/annotation metrics now opt-in to reduce memory usage[4]
- Helm chart moved to prometheus-community repository[1][6]
Recent vulnerability patches (CVE-2025-22866) were also backported to this release[9]. Operators should review the full CHANGELOG for upgrade considerations[4][8].
Citations:
- 1: https://kubernetes.io/blog/2021/04/13/kube-state-metrics-v-2-0/
- 2: https://last9.io/blog/kube-state-metrics/
- 3: https://aws.amazon.com/marketplace/pp/prodview-2rojcv22tdrcq
- 4: https://github.com/kubernetes/kube-state-metrics/blob/main/CHANGELOG.md
- 5: https://www.densify.com/kubernetes-tools/kube-state-metrics/
- 6: https://artifacthub.io/packages/helm/prometheus-community/kube-state-metrics/5.15.2
- 7: https://grafana.com/docs/grafana-cloud/monitor-infrastructure/kubernetes-monitoring/configuration/config-other-methods/k8s-agent-static/
- 8: https://github.com/kubernetes/kube-state-metrics/releases
- 9: https://security.snyk.io/vuln/SNYK-CHAINGUARDLATEST-KUBESTATEMETRICS-8705312
- 10: https://docs-bigbang.dso.mil/2.15.0/packages/monitoring/CHANGELOG/
- 11: https://github.com/kubernetes/kube-state-metrics
- 12: https://hub.docker.com/layers/bitnami/kube-state-metrics/2.15.0-debian-12-r6/images/sha256-4e98a24e281ee716286383cfb31ae8c505b5b0ddae026097c84b89b99e2fd784
- 13: https://github.com/kubernetes/kube-state-metrics/blob/master/examples/standard/deployment.yaml
- 14: https://docs.datadoghq.com/integrations/kubernetes_state_core/
- 15: https://grafana.com/docs/grafana-cloud/monitor-infrastructure/kubernetes-monitoring/configuration/manage-configuration/
- 16: https://forum.newrelic.com/s/hubtopic/aAX8W0000008bzlWAA/kubestatemetrics-version-compatibility
- 17: https://cloud.google.com/monitoring/docs/release-notes
- 18: https://artifacthub.io/packages/helm/prometheus-community/kube-state-metrics/?modal=values
- 19: https://hub.docker.com/r/bitnami/kube-state-metrics/tags/
- 20: https://artifacthub.io/packages/helm/prometheus-community/kube-state-metrics
Approved: Correct Version and Maintainer Information
The chart update correctly bumps
appVersionto 2.15.0—aligning with the latest kube-state-metrics release that introduces improvements in metrics, stability, and security—and updates the overall chart version to 5.30.1. Additionally, the maintainer GitHub URLs have been added, which improves documentation and follows best practices.
- File:
packages/system/monitoring-agents/charts/kube-state-metrics/Chart.yaml- Lines Impacted: 7, 18, 21, 24, 29
No issues were found upon verification.
packages/system/monitoring-agents/charts/prometheus-node-exporter/Chart.yaml (1)
7-7:Details
✅ Verification successful
Version updates and maintainer URLs are correctly configured
The chart has been updated to use node-exporter 1.9.0 and chart version 4.44.1. Maintainer GitHub URLs have been added, which improves documentation and follows best practices.
Also applies to: 17-17, 20-20, 23-23, 28-28
🌐 Web query:
What's new in prometheus node-exporter 1.9.0 compared to previous versions?💡 Result:
Prometheus Node Exporter 1.9.0 introduces significant updates compared to previous versions, including new collectors, enhanced filtering capabilities, and expanded OS support. Here are the key changes:
New Features
- Filesystem metrics: Added
node_filesystem_mount_infometric for detailed mount point information[1][3]- BTRFS monitoring: Metrics for commit statistics (#3010)[1][3]
- Interrupt filtering: Include/exclude filters and zero-value exclusion in interrupts collector (#3028)[1][3]
- Hardware monitoring:
- Network enhancements: ifAlias label for netdev metrics (#3087)[1][3]
- New collectors:
- Platform support: Added AIX and improved NetBSD compatibility (#3136, #3082)[1][3]
Enhancements
- Filtering controls: New
exclude[]URL parameter for dynamic collector exclusion (#3116)[1][3]- CPU monitoring: Support for online/offline CPU status tracking (#3032)[1][3]
- Disk metrics: Added block device rotational status (#3022)[1][3]
- Ethtool optimization: Reduced filesystem scanning overhead (#3239)[1][3]
- MacOS integration: Purgeable space reporting for filesystems (#3206)[1][3]
- Logging modernization: Migrated to Go's log/slog package (#3097)[1][3]
Changes and Fixes
- Memory handling: Rewritten Linux meminfo collection using procfs library (#3049)[1][3]
- ZFS improvements: Fixed potential memory leaks in ZFS collector[1][3]
- ARP optimization: Faster interface name resolution (#3133)[1][3]
- Textfile collector: Support for multiple directory glob patterns (#3135)[1][3]
Compared to version 1.6.0 (2023-05-27), 1.9.0 adds 15+ new metrics and substantially improves filtering flexibility. The update also introduces breaking changes in metric collection methods for memory statistics and logging infrastructure[1][3][7]. Users upgrading from versions prior to 1.8.0 should review collector flag changes and new filtering capabilities to optimize metric collection[1][3][9].
Citations:
- 1: https://github.com/prometheus/node_exporter/releases
- 2: https://groups.google.com/g/prometheus-users/c/APhRZS_c68Q/m/gmHPdk4ACQAJ
- 3: https://github.com/prometheus/node_exporter/blob/master/CHANGELOG.md
- 4: https://github.com/prometheus/node_exporter
- 5: https://grafana.com/docs/grafana-cloud/send-data/metrics/metrics-prometheus/prometheus-config-examples/docker-compose-linux/
- 6: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/observability-prgrja-example
- 7: https://launchpad.net/ubuntu/+source/prometheus-node-exporter/+changelog
- 8: https://tracker.debian.org/prometheus-node-exporter
- 9: https://raw.githubusercontent.com/prometheus/node_exporter/master/CHANGELOG.md
- 10: https://aerospike.com/docs/monitorstack/install/linux
- 11: https://dev.to/coder7475/how-to-set-up-a-system-monitoring-for-linux-server-using-node-exporter-prometheus-grafana-1ja7
- 12: https://grafana.com/docs/grafana-cloud/send-data/metrics/metrics-prometheus/prometheus-config-examples/noagent_linuxnode/
- 13: https://download.aerospike.com/download/monitoring/aerospike-prometheus-exporter/notes.html
- 14: https://docs.fluentbit.io/manual/pipeline/inputs/windows-exporter-metrics
- 15: https://artifacthub.io/packages/helm/prometheus-community/prometheus-node-exporter/1.9.0
- 16: https://manpages.debian.org/testing/prometheus-node-exporter/prometheus-node-exporter.1.en.html
- 17: https://sourceforge.net/projects/node-exporter.mirror/
- 18: https://docs.fluentbit.io/manual/pipeline/inputs/node-exporter-metrics
- 19: https://artifacthub.io/packages/helm/prometheus-community/prometheus-operator/1.9.0
- 20: https://bitnami.com/stack/node-exporter
Approved Update Verification
The chart has been updated to use Prometheus Node Exporter 1.9.0 (bringing several enhancements such as new collectors and improved filtering mechanisms) and chart version 4.44.1. Additionally, the maintainer GitHub URLs have been added to improve documentation and follow best practices.
- File: packages/system/monitoring-agents/charts/prometheus-node-exporter/Chart.yaml (Line 7:
appVersion: 1.9.0)- Similar updates have been applied at lines 17, 20, 23, and 28.
packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/_helpers.tpl (2)
204-222: Default node affinity properly excludes incompatible node typesThe default node affinity configuration correctly excludes AWS Fargate and Azure virtual nodes, which are not compatible with node-exporter (as it requires direct node access).
223-237: Well-implemented affinity merging logicThe merging logic elegantly combines default affinity rules with user-provided ones, ensuring that:
- Default node affinity rules are always applied
- User-provided affinity rules can override or extend the defaults
- Pod affinity and anti-affinity can be added by users
This approach provides both safety and flexibility.
packages/system/monitoring-agents/charts/prometheus-node-exporter/values.yaml (5)
48-48: Update kubeRBACProxy Image Tag
The image tag has been updated from a previous version to v0.18.2. This change is straightforward and aligns with updating to a newer release version.
87-92: Add Extra Volume Mounts for Kube-RBAC-Proxy
A new section forextraVolumeMountsunder thekubeRBACProxyconfiguration has been introduced. This addition allows users to inject additional mounts into the kube-rbac-proxy container. Ensure that any required documentation or examples are updated accordingly.
94-117: Introduce TLS Configuration for Kube-RBAC-Proxy
New TLS-related settings have been added, including atlsblock (to enable TLS and client certificate authentication) and atlsSecretblock (to reference an existing secret containing TLS assets). These additions enhance security when TLS is required. Please confirm that the reference paths (e.g./tls/private) and the expectation for secret keys (liketls.crt,tls.key, and optionallycaItem) are correctly documented and tested.
182-187: Add Target Labels for Node Exporter Metrics
The configuration now includes a new field fortargetLabels(with an accompanying comment referencing Prometheus Operator documentation). This provides users the flexibility to specify extra labels for node exporter metrics. Verify that any downstream templates consume this value as expected.
603-616: Define Extra Volumes and Volume Mounts for the Pod
New sections forextraVolumesandextraVolumeMountshave been added, allowing additional volumes and mounts to be defined in the pod. This improves customizability. Please ensure that users are aware (via documentation) of how these sections interact with other volume settings in the chart.packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/daemonset.yaml (2)
199-205: Conditional TLS Arguments in Kube-RBAC-Proxy Args
A new conditional block has been added to supply TLS arguments (--tls-cert-file,--tls-private-key-file, and optionally--client-ca-file) to the kube-rbac-proxy container when both TLS and tlsSecret are enabled. This improves security by enforcing TLS when configured. Please verify that these arguments work as intended in your test environments.
209-216: Add TLS Volume Mount and Extra Volume Mounts for Kube-RBAC-Proxy
Within the kube-rbac-proxy container definition, a volume mount for the TLS secret (mounted at/tls/private) has been added conditionally, along with support for additional volume mounts viakubeRBACProxy.extraVolumeMounts. Ensure that the templating for the secret volume name (tpl .Values.tlsSecret.volumeName . | quote) is correct and consistent with your secret creation.packages/system/monitoring-agents/charts/fluent-bit/values.yaml (2)
518-519: Update HotReload Image Tag for Fluent Bit
The hotReload image tag has been updated from v0.11.1 to v0.14.0. This likely brings improvements and bug fixes from the upstream image. Ensure that the new version is compatible with your overall Fluent Bit configuration.
522-523: Introduce Extra Watch Volumes for HotReload
An empty array forextraWatchVolumeshas been added under the hotReload section. This change provides a placeholder for additional volumes that might be needed for watching configuration changes. Confirm whether any additional volumes will be specified in the future or if this serves as a customizable default.packages/system/monitoring-agents/charts/kube-state-metrics/templates/deployment.yaml (4)
177-180: Startup Probe Adjustment for Kube-RBAC-Proxy
The startup probe now conditionally sets the port and scheme to use HTTPS when the kubeRBACProxy is enabled. This is a sensible approach to match the secured endpoint configuration. Please verify that the chosen port (.Values.service.port | default 8080) and scheme are consistent with other probe settings.
200-207: Liveness Probe Update to Support HTTPS via Kube-RBAC-Proxy
The liveness probe has been updated similarly to the startup probe to use HTTPS and the default service port when kubeRBACProxy is enabled. This consistency with the secure configuration is beneficial—double-check that these settings do not conflict with any service-level overrides.
223-230: Readiness Probe Configured for Telemetry with Secure Scheme
The readiness probe now conditionally uses the telemetry port and sets its scheme to HTTPS when kubeRBACProxy is active. This ensures that your metrics endpoint is correctly probed securely. Please confirm that the telemetry port (sourced from.Values.selfMonitor.telemetryPort | default 8081) is the intended one.
347-366: Conditional Volume Mounts for Additional Resources
The volumes section now conditionally appends volumes for kubeconfig, custom resource state, and kubeRBACProxy configuration based on enabled flags. This modular approach is clear and maintains flexibility. Ensure that all referenced secrets/configMaps exist and that the volume names and mount paths meet your cluster’s security requirements.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (11)
packages/system/monitoring-agents/charts/fluent-bit/templates/tests/test-connection.yaml (1)
19-20: Configurable Delay for Connection ReliabilityThe updated command now introduces a fixed 5-second delay before executing
wget, which can help ensure the target service is ready before making the connection attempt. Consider making this delay configurable via a value in your Helm chart (for example,.Values.testFramework.connectionDelay) so that adjustments can be made easily across different deployment environments without modifying the template directly.packages/system/monitoring-agents/values.yaml (1)
31-32: Enhance kube-state-metrics with Extra ArgumentsThe addition of
extraArgsfor kube-state-metrics—specifically the allowlist argument for pods and deployments—improves control over metric labeling. Consider adding an inline comment or documentation note that explains the purpose and usage of this argument for future maintainers.packages/system/monitoring-agents/charts/fluent-bit/Chart.yaml (1)
4-7: Version and Description Update ConsistencyThe updates to the chart's metadata—updating the OCI image reference in the description, along with the
appVersion(3.2.8) andversion(0.48.9)—are consistent and clear. Ensure these version bumps are communicated in your release notes or CHANGELOG for traceability.packages/system/monitoring-agents/charts/fluent-bit/templates/configmap-luascripts.yaml (1)
11-11: Enable Template Rendering for Lua ScriptsChanging the Lua scripts processing to use the
tplfunction before quoting them enables dynamic templating based on the current context. This enhancement should be reflected in your documentation and example values to ensure users understand and can leverage the new functionality effectively.packages/system/monitoring-agents/charts/kube-state-metrics/templates/deployment.yaml (1)
68-76: Conditional Environment Variable ConfigurationThe template now handles additional environment variables differently depending on whether autosharding is enabled. In the autosharding branch, extra variables are merged after the POD name/namespace settings, while in the else branch an explicit
env:key is added. Please verify that the generated YAML is valid in both scenarios and that there’s no duplication or omission of required keys.packages/system/monitoring-agents/charts/fluent-bit/templates/_pod.tpl (1)
142-142: Minor whitespace changeThere's an extra space at the end of this line, which doesn't affect functionality.
- name: {{ include "fluent-bit.fullname" . }}-luascripts + name: {{ include "fluent-bit.fullname" . }}-luascriptspackages/system/monitoring-agents/charts/fluent-bit/values.yaml (1)
48-52: Enhanced Pod Security Policy ConfigurationsNew keys
runAsUser(with ruleRunAsAny) andseLinux(with ruleRunAsAny) have been added under thepodSecurityPolicysection. These more permissive settings can be useful for flexibility; however, please verify that they align with your organization’s security guidelines and cluster policies.packages/system/monitoring-agents/charts/prometheus-node-exporter/values.yaml (3)
87-93: Added Extra Volume Mounts for kubeRBACProxyAn empty
extraVolumeMountsarray is now provided under the kubeRBACProxy configuration. This addition offers flexibility for mounting additional volumes if required. Consider adding an example or documentation note to help users understand when and how to use this option.
94-100: Introduced TLS Configuration for kubeRBACProxyA new
tlsblock has been added underkubeRBACProxyto allow TLS options (including client authentication) when needed. Verify that these settings match your intended security posture and that they integrate seamlessly with your existing TLS infrastructure.
562-572: Vertical Pod Autoscaler Support AddedA new
verticalPodAutoscalerblock is introduced (currently disabled by default). This feature will allow autoscaling based on resource recommendations. Review the default values—particularly fields likecontrolledResourcesand resource limits—to ensure they are tuned to your workload requirements before enabling this feature.packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/daemonset.yaml (1)
332-348: Enhanced TLS Secret Volume Definition in DaemonSetA secret volume is conditionally defined for TLS (using the provided
tlsSecretconfiguration) at the bottom of the volumes list. This setup requires thatcertItemandkeyItemare set (with an optionalcaItem). Please ensure that your secret contains these keys and that the volume is correctly mounted to support the kube-rbac-proxy’s TLS arguments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (36)
packages/system/monitoring-agents/charts/fluent-bit/Chart.yaml(2 hunks)packages/system/monitoring-agents/charts/fluent-bit/README.md(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/ci/ci-values.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/NOTES.txt(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/_pod.tpl(2 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/configmap-luascripts.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/psp.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/scc.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/tests/test-connection.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/templates/vpa.yaml(1 hunks)packages/system/monitoring-agents/charts/fluent-bit/values.yaml(5 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/Chart.yaml(2 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/templates/deployment.yaml(5 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/templates/role.yaml(1 hunks)packages/system/monitoring-agents/charts/kube-state-metrics/values.yaml(4 hunks)packages/system/monitoring-agents/charts/metrics-server/RELEASE.md(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/.helmignore(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/Chart.yaml(2 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/README.md(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/common-labels-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/default-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/networkpolicy-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/pod-labels-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/port-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/service-labels-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/serviceport-values.yaml(0 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/NOTES.txt(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/_helpers.tpl(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/daemonset.yaml(4 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/psp-clusterrole.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/rbac-configmap.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/serviceaccount.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/servicemonitor.yaml(1 hunks)packages/system/monitoring-agents/charts/prometheus-node-exporter/values.yaml(8 hunks)packages/system/monitoring-agents/values.yaml(1 hunks)packages/system/vertical-pod-autoscaler/values.yaml(1 hunks)
💤 Files with no reviewable changes (7)
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/serviceport-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/default-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/port-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/service-labels-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/common-labels-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/pod-labels-values.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/ci/networkpolicy-values.yaml
✅ Files skipped from review due to trivial changes (9)
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/serviceaccount.yaml
- packages/system/monitoring-agents/charts/metrics-server/RELEASE.md
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/rbac-configmap.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/.helmignore
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/psp-clusterrole.yaml
- packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/NOTES.txt
- packages/system/monitoring-agents/charts/prometheus-node-exporter/README.md
- packages/system/monitoring-agents/charts/fluent-bit/templates/vpa.yaml
- packages/system/monitoring-agents/charts/fluent-bit/templates/NOTES.txt
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/system/vertical-pod-autoscaler/values.yaml
🔇 Additional comments (41)
packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/_helpers.tpl (2)
204-222: Well-implemented node affinity for monitoring exclusionsThe default node affinity configuration correctly excludes AWS Fargate and Azure virtual-kubelet nodes, which is essential since these serverless environments typically don't support the privileged access needed for node exporters to collect metrics.
223-237: Good implementation of affinity merging logicThis template efficiently merges default affinity with user-defined values, providing flexibility while maintaining essential constraints. The use of
mergeOverwritefor nodeAffinity ensures user configurations take precedence while preserving defaults where not specified, and the direct assignment of podAffinity/podAntiAffinity allows for complete user customization of these properties.packages/system/monitoring-agents/charts/fluent-bit/README.md (1)
30-30: Clarify Lua Scripts Templating SupportThe instructional text now explicitly states that templating is supported when adding Lua scripts to
luaScriptsinvalues.yaml. This improves clarity for users who wish to leverage dynamic content generation within their Lua scripts.packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/servicemonitor.yaml (1)
19-22: Introducing Target Labels for ServiceMonitorThe new block for
targetLabelsin the ServiceMonitor configuration is well structured and aligns with the existingpodTargetLabelsblock. This addition provides enhanced flexibility for label selection. Be sure that the corresponding values are appropriately documented and configured in your values files.packages/system/monitoring-agents/charts/kube-state-metrics/templates/role.yaml (4)
108-113: New Rule for "ingressclasses" ResourceThis block conditionally adds permissions for the "ingressclasses" resource when enabled in the collectors values. The structure follows the established pattern. Just ensure that "ingressclasses" is documented in your values file so users know to opt it in if needed.
114-119: New Rule for "clusterrolebindings" ResourceThe newly introduced block for "clusterrolebindings" is consistent with the other rules. It grants "list" and "watch" permissions over the appropriate API group. Verify that your RBAC requirements include this resource.
120-125: New Rule for "clusterroles" ResourceAdding this conditional block to grant access to "clusterroles" follows the existing template style. Make sure that this permission is really needed so that you don’t inadvertently expose extra privileges.
126-131: New Rule for "roles" ResourceThis block adds listing and watching capabilities for "roles" from the RBAC API group. The implementation is sound; just confirm that enabling it via collectors in your values file aligns with your security policies.
packages/system/monitoring-agents/charts/fluent-bit/templates/psp.yaml (2)
23-26: Dynamic runAsUser ConfigurationThe new block leverages the value from
.Values.podSecurityPolicy.runAsUserto dynamically render therunAsUserfield. This increases flexibility compared to a hardcoded value. Ensure that users provide a valid structure in their values.
27-30: Dynamic seLinux ConfigurationSimilarly, the block for the
seLinuxfield now utilizes.Values.podSecurityPolicy.seLinuxwithtoYamlformatting. This change allows for custom SELinux settings. Please double-check the indentation in various deployment environments.packages/system/monitoring-agents/charts/kube-state-metrics/values.yaml (2)
109-109: Updated kubeRBACProxy Image TagThe image tag for the kubeRBACProxy component has been updated to
v0.18.2. Make sure that this version has been verified for compatibility and that there are no known vulnerabilities.
163-169: Addition of Environment Variables SectionA new (currently empty) environment variables section has been added. This change provides users a hook to inject additional environment settings (e.g. setting
GOMAXPROCS). Please update the documentation accordingly so users know how to use this section.packages/system/monitoring-agents/charts/kube-state-metrics/Chart.yaml (3)
7-7: Updated appVersion FieldThe
appVersionhas been bumped to2.15.0, reflecting the new release. Ensure all feature changes are compatible with this version update.
16-24: Enhanced Maintainer InformationMaintainer entries now include URL fields for GitHub profiles (for example, for
tariq1890,mrueg, anddotdc). This additional metadata improves traceability and transparency.
29-29: Chart Version BumpThe chart version has been updated to
5.30.1. Confirm that this version increment is properly reflected in your release notes and that any compatibility-breaking changes are documented.packages/system/monitoring-agents/charts/kube-state-metrics/templates/deployment.yaml (6)
82-84: Added "--host=127.0.0.1" Argument for kubeRBACProxyWhen kubeRBACProxy is enabled, the deployment injects
--host=127.0.0.1into the container’s arguments. This ensures that the proxy listens on the loopback interface. Confirm that this setting does not conflict with any other networking configurations.
177-183: Conditional Startup Probe ConfigurationThe startup probe now conditionally sets its port and scheme: using the service port with HTTPS when kubeRBACProxy is enabled, otherwise reverting to the configured defaults. This dynamic configuration should be validated to ensure that health checks work as intended in both cases.
201-207: Conditional Liveness Probe ConfigurationThe liveness probe section similarly adapts its settings based on the kubeRBACProxy status. Please verify that the
$servicePortvariable is correctly computed and that the HTTPS configuration is appropriate when enabled.
224-230: Conditional Readiness Probe ConfigurationFor the readiness probe, the template now uses the telemetry port with HTTPS when kubeRBACProxy is enabled, and falls back to default values otherwise. Double-check that these configurations align with the expected endpoint behavior.
241-317: New Containers for kube-rbac-proxy and TelemetryTwo new container blocks have been added: one for handling HTTP proxying (
kube-rbac-proxy-http) and another for telemetry (kube-rbac-proxy-telemetry, when self-monitoring is enabled). These blocks include custom arguments, volume mounts, and tailored readiness probes. Verify that the referenced ConfigMap (for proxy configuration) is generated correctly and that the port assignments do not conflict with other services.
326-332: Affinity Section Conditional FormattingThe affinity configuration now conditionally distinguishes between a map and a templated string. This added flexibility is helpful for varied user inputs. No issues noted as long as the intended structure is maintained.
packages/system/monitoring-agents/charts/fluent-bit/ci/ci-values.yaml (5)
6-10: Extra volume mounts provide additional flexibilityThese new volume mount configurations allow for extending Fluent Bit with additional storage locations, which is useful for custom configurations or log processing.
12-16: Extra volumes properly defined as empty directoriesThese volume definitions correspond to the mount points defined above, creating empty directories that can be used for runtime data or temporary storage.
22-32: Good examples of Lua scripts with templating capabilityThe added Lua script examples demonstrate both basic filtering and how to use Helm templating within scripts, which is valuable for users who need to create custom log filters.
33-37: Simple stdout output configuration for easier debuggingThis configuration sends all matched logs to stdout, which is useful for debugging and testing Fluent Bit configurations.
39-43: Hot reload configuration references the new volumesThe hot reload feature is properly configured to watch the extra volumes defined earlier, ensuring that changes to files in those volumes will trigger a configuration reload.
packages/system/monitoring-agents/charts/fluent-bit/templates/scc.yaml (2)
27-30: Improved flexibility for OpenShift runAsUser configurationReplacing the static configuration with dynamic templating allows users to customize the runAsUser settings through Helm values, which is important for OpenShift security context constraints.
31-34: Enhanced seLinuxContext configuration with templatingSimilar to the runAsUser change, this improvement allows for dynamic configuration of seLinuxContext through Helm values, providing better flexibility for different OpenShift environments.
packages/system/monitoring-agents/charts/fluent-bit/templates/_pod.tpl (2)
111-113: Dynamic configuration of volume directories for hot reloadThis loop effectively adds each extra watch volume as a volume directory argument to the reloader container, enabling it to monitor custom volumes for changes.
119-122: Corresponding volume mounts for extra watch volumesThese volume mounts correctly match the volume directory arguments added above, ensuring that the reloader container has access to the volumes it needs to monitor.
packages/system/monitoring-agents/charts/prometheus-node-exporter/Chart.yaml (3)
7-7: Updated appVersion to 1.9.0The prometheus-node-exporter version has been updated from 1.8.2 to 1.9.0, which is a good practice to stay current with the latest features and bug fixes.
17-17: Added GitHub URLs for maintainersAdding GitHub profile URLs for each maintainer improves the chart's metadata and makes it easier for users to contact or follow the maintainers.
Also applies to: 20-20, 23-23
28-28: Updated chart version to 4.44.1The Helm chart version has been updated from 4.40.0 to 4.44.1, which is appropriate when updating the underlying application version and making other changes to the chart.
packages/system/monitoring-agents/charts/fluent-bit/values.yaml (2)
62-65: OpenShift Security Context AdjustmentsUnder the
openShiftsection, the addedrunAsUsertype (RunAsAny) andseLinuxContexttype (MustRunAs) help tailor security settings for OpenShift deployments. Confirm that these settings meet your environment’s security standards, as they may be less restrictive than some production policies.
518-523: HotReload Configuration UpdateThe
hotReloadsection now uses the image tagv0.14.0(upgraded from an earlier version) and has an emptyextraWatchVolumesarray added. This increases configurability for users who may wish to mount custom volumes for hot reloading. Please ensure that the accompanying documentation in the chart notes is updated to explain how to use this new option.packages/system/monitoring-agents/charts/prometheus-node-exporter/values.yaml (3)
47-49: Updated kubeRBACProxy Image TagThe image tag for the
kubeRBACProxyhas been updated tov0.18.2, which should incorporate the latest improvements and security fixes. This change appears appropriate to keep the deployment up to date.
101-117: Added TLS Secret ConfigurationThe
tlsSecretsection now defines the parameters required to reference an existing secret (including certificate, key, and optionally CA certificate). Please ensure that the key names (e.g.tls.crt,tls.key) match your secret’s structure and that this configuration is documented for users deploying with TLS.
181-188: Added Target Labels for Node Exporter MetricsThe configuration now includes settings for
podTargetLabelsandtargetLabels, which can be used to add additional labels to the node exporter metrics. This can help in refining Prometheus monitoring. Verify that these labels are consistent with your ServiceMonitor and Prometheus Operator configurations.packages/system/monitoring-agents/charts/prometheus-node-exporter/templates/daemonset.yaml (3)
181-183: Inclusion of Extra Volume Mounts for Node ExporterThe template now conditionally includes extra volume mounts via
.Values.extraVolumeMountsin the main node exporter container. This improves flexibility; just ensure that any additional mounts are clearly defined in your chart values when needed.
199-205: Conditional TLS Arguments for kube-rbac-proxyWithin the kube-rbac-proxy container’s argument list, TLS arguments (
--tls-cert-fileand--tls-private-key-file, with an optional--client-ca-file) are conditionally included when both TLS and the corresponding secret are enabled. Please verify that the file paths (/tls/private/...) correctly match the TLS secret volume mount.
207-217: TLS Secret Volume Mount and Additional Volume MountsA new volume mount for the TLS secret is defined (mounted at
/tls/private) under the kube-rbac-proxy container, alongside the inclusion of any extra volume mounts via.Values.kubeRBACProxy.extraVolumeMounts. Confirm that these paths and volume names align with thetlsSecretconfiguration in your values.
Summary by CodeRabbit
New Features
VerticalPodAutoscalerandVerticalPodAutoscalerCheckpoint.vertical-pod-autoscalerincluding resource limits and requests for various components.kube-state-metricsandprometheus-node-exportercharts.Chores
Tests