Skip to content

Openhab - #969

Open
drieks wants to merge 1 commit into
helmforgedev:mainfrom
drieks:openhab
Open

Openhab#969
drieks wants to merge 1 commit into
helmforgedev:mainfrom
drieks:openhab

Conversation

@drieks

@drieks drieks commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Switch the openHAB default persistence layout from three PVCs to one shared, release-specific data PVC.
  • Mount userdata, conf, and addons through configurable subPaths and create those directories in an init container.
  • Support a shared existing claim or separate per-directory existing claims; add validation, tests, and storage documentation.

Type Of Change

  • New chart
  • Existing chart change
  • Documentation only
  • CI / repository workflow

PR Governance

  • I linked an existing issue in this PR body (Resolves #NNN or Related to #NNN)
  • If this is a new chart PR, labels enhancement and type:feature are applied

Checklist

  • I created this branch from updated main
  • My PR targets main
  • My commit message and PR title follow Conventional Commits
  • I did not edit version in Chart.yaml manually
  • I updated the root README.md if a new chart was added or public chart metadata changed
  • I updated values.schema.json for any values changes
  • I updated chart docs for behavior or default changes

Upstream Verification

  • I verified appVersion in Chart.yaml matches the real upstream release
  • I confirmed the image tag in values.yaml corresponds to a published, stable tag
  • I cross-referenced upstream GitHub Releases and Docker Hub tags

Site Sync (GR-007)

If this change affects chart defaults, install path, architecture, backup, or maturity:

  • I updated the corresponding page in site/ repository
  • N/A — this change does not affect public documentation

Local Validation

  • I confirmed kubectl config current-context before local installs/upgrades/uninstalls
  • helm lint charts/openhab --strict passed
  • helm unittest charts/openhab passed
  • All relevant ci/*.yaml scenarios rendered successfully
  • I validated this change on a local k3d cluster when required
  • I validated the default install
  • I validated at least one main non-default scenario for this change
  • If backup behavior changed, I validated the flow against local MinIO

Notes

  • openhab does not start when using longhorn as PVC backend because ext4 creates a lost+found directory and openhab does not handle such PVCs as empty. on first start no template data is copied into such PVCs.
  • helm lint charts/openhab --strict and all charts/openhab/ci/*.yaml renders passed.
  • helm unittest charts/openhab currently fails immediately with EOF in backup_test.yaml using Helm 4.2.2 and helm-unittest 0.6.3; no tests were executed.
  • No upstream image/app version change is included in this PR.

Summary by CodeRabbit

  • New Features

    • Added support for sharing one PVC across userdata, configuration, and addons.
    • Added configurable subpaths and centralized settings for generated claims.
    • Added support for existing shared or separate claims.
  • Bug Fixes

    • Added validation for conflicting claims, invalid subpaths, and unsupported configurations.
    • Automatically creates required persistence directories.
    • Improved shared volume mounts and backup path handling.
  • Documentation

    • Updated storage guidance, migration steps, and PVC initialization warnings.

@coderabbitai

coderabbitai Bot commented Aug 10, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The openHAB chart now supports shared or dedicated PVCs with centralized claim settings, configurable relative subpaths, validation, subpath initialization, backup handling, deduplicated volume declarations, and updated documentation and tests.

Changes

openHAB persistence

Layer / File(s) Summary
Persistence configuration contract
charts/openhab/values.yaml, charts/openhab/values.schema.json, charts/openhab/docs/storage.md, charts/openhab/README.md, charts/openhab/DESIGN.md, charts/openhab/UPGRADING.md
The chart defines shared claim settings, existing-claim options, and relative subpaths for userdata, conf, and addons. The documentation describes supported layouts and migration steps.
Claim resolution and validation
charts/openhab/templates/_helpers.tpl, charts/openhab/templates/pvc.yaml, charts/openhab/templates/NOTES.txt
The chart validates claim combinations, resolves shared or dedicated claims, generates volume names, renders managed PVCs, and reports the selected claim configuration.
Subpath initialization and mounting
charts/openhab/templates/statefulset.yaml, charts/openhab/templates/backup-cronjob.yaml
The chart creates configured persistence directories, applies subpaths to StatefulSet and backup mounts, and deduplicates persistent volume declarations.
Persistence behavior tests
charts/openhab/tests/pvc_test.yaml, charts/openhab/tests/statefulset_test.yaml, charts/openhab/tests/backup_test.yaml, charts/openhab/tests/validation_test.yaml
Tests cover dedicated and shared PVCs, existing claims, generated volume names, subpath initialization, backup mounts, and invalid persistence configurations.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Values as Helm values
  participant Validation as openhab.validatePersistence
  participant Templates as PVC and StatefulSet templates
  participant InitContainer as persistence init container
  participant Pod as openHAB pod
  Values->>Validation: Supply claim and subPath settings
  Validation->>Templates: Validate and resolve claims
  Templates->>InitContainer: Render required persistence mounts
  InitContainer->>Pod: Create configured subdirectories
  Templates->>Pod: Mount shared or dedicated claims at subPaths
Loading

Possibly related PRs

Suggested labels: enhancement, type:feature

Suggested reviewers: mberlofa

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name Status Explanation Resolution
Title check ❓ Inconclusive The title identifies openHAB but does not describe the shared PVC and configurable subpath changes. Use a specific title such as "feat(openhab): support shared PVCs and configurable subpaths".
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot added the enhancement New feature or request label Aug 10, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@charts/openhab/templates/backup-cronjob.yaml`:
- Around line 49-59: Update the backup CronJob pod template by adding a writable
init container before the backup container that mounts each selected PVC at its
root and runs mkdir -p for the configured userdata and conf subPaths. Ensure it
handles only enabled backup volumes, while preserving the existing read-only
subPath mounts in the backup container.

In `@charts/openhab/values.schema.json`:
- Around line 218-236: Update the persistence schema and chart upgrade path so
legacy per-directory settings under persistence.userdata, persistence.conf, and
persistence.addons are not accepted and ignored; either reject them through
template validation or explicitly migrate them into persistence.claim. Ensure
existing releases cannot silently fall back to the claim default of 5Gi, and
document the required upgrade procedure before release.

In `@charts/openhab/values.yaml`:
- Around line 116-141: Update charts/openhab/values.yaml lines 116-141 and
charts/openhab/README.md lines 139-150 to describe userdata, conf, and addons as
mounting their resolved or selected PVC, covering both shared and separate
existing-claim modes. Update charts/openhab/templates/NOTES.txt lines 77-97 to
derive the displayed label from the resolved claim mode and omit
persistence.claim.size when an existing claim is used; preserve capacity output
for chart-generated claims.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ff65f1ed-54b4-479f-b1d3-11a2bfdb7aa4

📥 Commits

Reviewing files that changed from the base of the PR and between 5fa51a1 and e23cfea.

📒 Files selected for processing (12)
  • charts/openhab/README.md
  • charts/openhab/docs/storage.md
  • charts/openhab/templates/NOTES.txt
  • charts/openhab/templates/_helpers.tpl
  • charts/openhab/templates/backup-cronjob.yaml
  • charts/openhab/templates/pvc.yaml
  • charts/openhab/templates/statefulset.yaml
  • charts/openhab/tests/pvc_test.yaml
  • charts/openhab/tests/statefulset_test.yaml
  • charts/openhab/tests/validation_test.yaml
  • charts/openhab/values.schema.json
  • charts/openhab/values.yaml

Comment thread charts/openhab/templates/backup-cronjob.yaml Outdated
Comment on lines +218 to +236
"claim": {
"type": "object",
"description": "Settings for the generated data PVC",
"properties": {
"storageClass": {
"type": "string"
},
"accessMode": {
"type": "string",
"enum": ["ReadWriteOnce", "ReadWriteMany", "ReadOnlyMany"],
"default": "ReadWriteOnce"
},
"size": {
"type": "string",
"pattern": "^[0-9]+(Mi|Gi|Ti|M|G|T)$",
"default": "5Gi"
}
}
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Prevent silent loss of per-directory storage settings on upgrade.

The schema still accepts persistence.userdata, persistence.conf, and persistence.addons storage settings. The generated PVC reads only persistence.claim. Existing release values can therefore be accepted but ignored, and the chart can provision the default 5Gi claim instead.

Reject the obsolete settings with template validation, or migrate them explicitly. Add an upgrade procedure before release. Do not silently replace these settings.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/openhab/values.schema.json` around lines 218 - 236, Update the
persistence schema and chart upgrade path so legacy per-directory settings under
persistence.userdata, persistence.conf, and persistence.addons are not accepted
and ignored; either reject them through template validation or explicitly
migrate them into persistence.claim. Ensure existing releases cannot silently
fall back to the claim default of 5Gi, and document the required upgrade
procedure before release.

Comment thread charts/openhab/values.yaml Outdated
Comment on lines +116 to +141
# -- userdata: Runtime state, JSONDB, logs, persistence data (REQUIRED)
userdata:
# -- Mount userdata from the shared PVC
enabled: true
# -- Existing PVC for userdata (use this, conf.existingClaim and addons.existingClaim together for separate PVCs)
existingClaim: ""
# -- Subdirectory within the shared PVC to mount at /openhab/userdata
subPath: userdata

# -- conf: Configuration files synced before startup (REQUIRED)
conf:
# -- Enable PVC for conf
# -- Mount conf from the shared PVC
enabled: true
# -- Storage class name (empty = cluster default)
storageClass: ""
# -- Access mode
accessMode: ReadWriteOnce
# -- Storage size
size: 1Gi
# -- Use an existing PVC instead of creating one
# -- Existing PVC for conf (use this, userdata.existingClaim and addons.existingClaim together for separate PVCs)
existingClaim: ""
# -- Subdirectory within the shared PVC to mount at /openhab/conf
subPath: conf

# -- addons: Drop-in JAR addons not available via marketplace (optional)
addons:
# -- Enable PVC for addons
# -- Mount addons from the shared PVC
enabled: true
# -- Storage class name (empty = cluster default)
storageClass: ""
# -- Access mode
accessMode: ReadWriteOnce
# -- Storage size
size: 2Gi
# -- Use an existing PVC instead of creating one
# -- Existing PVC for addons (use this, userdata.existingClaim and conf.existingClaim together for separate PVCs)
existingClaim: ""
# -- Subdirectory within the shared PVC to mount at /openhab/addons
subPath: addons

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Describe the resolved PVC mode correctly.

The chart supports separate existing claims, but these texts always describe a shared PVC. The NOTES output can also report persistence.claim.size for an external claim whose capacity is unknown.

  • charts/openhab/values.yaml#L116-L141: replace “shared PVC” with “selected PVC” or describe the two supported modes.
  • charts/openhab/README.md#L139-L150: describe each mount as using its resolved PVC, not always the shared PVC.
  • charts/openhab/templates/NOTES.txt#L77-L97: derive the label from the resolved claim mode and omit generated-claim capacity for existing claims.
📍 Affects 3 files
  • charts/openhab/values.yaml#L116-L141 (this comment)
  • charts/openhab/README.md#L139-L150
  • charts/openhab/templates/NOTES.txt#L77-L97
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/openhab/values.yaml` around lines 116 - 141, Update
charts/openhab/values.yaml lines 116-141 and charts/openhab/README.md lines
139-150 to describe userdata, conf, and addons as mounting their resolved or
selected PVC, covering both shared and separate existing-claim modes. Update
charts/openhab/templates/NOTES.txt lines 77-97 to derive the displayed label
from the resolved claim mode and omit persistence.claim.size when an existing
claim is used; preserve capacity output for chart-generated claims.

@mberlofa

Copy link
Copy Markdown
Contributor

@drieks Thank you for the persistence improvements. I reviewed the current head (af6f342) and found the following items that should be addressed before this can be merged:

  1. The PR title currently fails the required Conventional Commits check. Please use a scoped title such as feat(openhab): support shared PVCs and configurable subpaths.
  2. The OpenHAB unit-test job fails in the two backup volume-mount assertions. The rendered mounts now include the default subPath (userdata or conf), but the expected objects in charts/openhab/tests/backup_test.yaml do not. Please update those expectations while preserving the read-only mounts.
  3. The persistence migration can silently ignore legacy per-directory storageClass, accessMode, and size values while provisioning the new default 5Gi shared claim. Please either reject those obsolete keys explicitly or migrate them, and document the required upgrade procedure.
  4. The persistence descriptions and NOTES output should distinguish generated shared claims, shared existing claims, and dedicated existing claims. In particular, NOTES should not report persistence.claim.size for an existing PVC whose capacity is unknown.

The backup subpath initializer itself is present in the current head, and its k3d backup-values scenario reached Ready with zero restarts during local review. The full validation was intentionally stopped after confirming this is an external contribution and should remain author-owned. Once the changes are pushed, CI and the complete make validate-chart CHART=openhab gate should be rerun.

@coderabbitai coderabbitai Bot added the type:feature Feature or enhancement change label Aug 11, 2026
@drieks

drieks commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

Hi @mberlofa,

how can I run the make commands?

make validate-chart CHART=openha

There are no makefiles in the repository and no description how to execute this commands..

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
charts/openhab/tests/backup_test.yaml (1)

3-5: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Assert the backup init container’s subPath mounts.

The subpath test checks only initContainers[0], create-backup-subpaths. Add assertions for initContainers[1], backup, to verify both mounts include the configured subPath and readOnly: true.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/openhab/tests/backup_test.yaml` around lines 3 - 5, Extend the tests
in backup_test.yaml for initContainers[1] named backup, asserting both volume
mounts use the configured subPath and readOnly: true, matching the existing
assertions for create-backup-subpaths.
🧹 Nitpick comments (1)
charts/openhab/tests/backup_test.yaml (1)

65-89: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Test the backup container subPath mounts.

This test verifies only create-backup-subpaths. It does not verify that the following backup init container mounts both claims with the configured subPath values and readOnly: true.

Add assertions for /openhab/userdata and /openhab/conf on initContainers[1]. This covers the runtime mounts that the initializer prepares.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/openhab/tests/backup_test.yaml` around lines 65 - 89, Add assertions
to the test for initContainers[1] (the backup container), verifying its volume
mounts use /openhab/userdata and /openhab/conf with the configured
shared/openhab/userdata and shared/openhab/conf subPath values and readOnly:
true for both claims. Keep the existing create-backup-subpaths assertions
unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@charts/openhab/templates/_helpers.tpl`:
- Around line 118-149: Update openhab.validatePersistence to validate shared-PVC
mode: when persistence.claim is enabled, reject differing legacy per-directory
size, storageClass, or accessMode overrides, or require explicit
persistence.claim settings before rendering. In charts/openhab/UPGRADING.md
lines 63-68, require the openHAB workload to be quiesced before copying data and
document prepopulating the chart-managed claim via a pre-provisioned shared
existingClaim before switching mounts.

In `@charts/openhab/templates/NOTES.txt`:
- Line 77: Update the NOTES descriptions for userdata, addons, and backups to
use the resolved claim source rather than only persistence.claim.enabled:
distinguish generated shared claims, shared existing claims, and dedicated
existing claims, and omit configured sizes whenever the PVC already exists. Add
Helm render coverage covering all three claim scenarios and verify the labels
and size suppression for each.

---

Outside diff comments:
In `@charts/openhab/tests/backup_test.yaml`:
- Around line 3-5: Extend the tests in backup_test.yaml for initContainers[1]
named backup, asserting both volume mounts use the configured subPath and
readOnly: true, matching the existing assertions for create-backup-subpaths.

---

Nitpick comments:
In `@charts/openhab/tests/backup_test.yaml`:
- Around line 65-89: Add assertions to the test for initContainers[1] (the
backup container), verifying its volume mounts use /openhab/userdata and
/openhab/conf with the configured shared/openhab/userdata and
shared/openhab/conf subPath values and readOnly: true for both claims. Keep the
existing create-backup-subpaths assertions unchanged.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 286c2793-393c-4d9c-8690-ab5f33d41cee

📥 Commits

Reviewing files that changed from the base of the PR and between e23cfea and 3885529.

📒 Files selected for processing (15)
  • charts/openhab/DESIGN.md
  • charts/openhab/README.md
  • charts/openhab/UPGRADING.md
  • charts/openhab/docs/storage.md
  • charts/openhab/templates/NOTES.txt
  • charts/openhab/templates/_helpers.tpl
  • charts/openhab/templates/backup-cronjob.yaml
  • charts/openhab/templates/pvc.yaml
  • charts/openhab/templates/statefulset.yaml
  • charts/openhab/tests/backup_test.yaml
  • charts/openhab/tests/pvc_test.yaml
  • charts/openhab/tests/statefulset_test.yaml
  • charts/openhab/tests/validation_test.yaml
  • charts/openhab/values.schema.json
  • charts/openhab/values.yaml
🚧 Files skipped from review as they are similar to previous changes (4)
  • charts/openhab/README.md
  • charts/openhab/values.schema.json
  • charts/openhab/values.yaml
  • charts/openhab/templates/statefulset.yaml

Comment on lines +118 to +149
{{- define "openhab.validatePersistence" -}}
{{- $volumes := dict "userdata" .Values.persistence.userdata "conf" .Values.persistence.conf "addons" .Values.persistence.addons }}
{{- range $name, $volume := $volumes }}
{{- if and (not $volume.enabled) $volume.existingClaim }}
{{- fail (printf "persistence.%s must be enabled when existingClaim is configured." $name) }}
{{- end }}
{{- if and (hasKey $volume "subPath") (not $volume.existingClaim) $.Values.persistence.claim.enabled }}
{{- fail (printf "persistence.%s.subPath requires existingClaim when persistence.claim.enabled is true." $name) }}
{{- end }}
{{- if and $volume.subPath (or (hasPrefix "/" $volume.subPath) (eq $volume.subPath ".") (eq $volume.subPath "..") (regexMatch "(^|/)\\.\\.(/|$)" $volume.subPath)) }}
{{- fail (printf "persistence.%s.subPath must be a relative path without traversal segments." $name) }}
{{- end }}
{{- end }}
{{- range $name, $volume := $volumes }}
{{- if and $volume.enabled $volume.existingClaim (not $volume.subPath) }}
{{- range $otherName, $otherVolume := $volumes }}
{{- if and (ne $name $otherName) $otherVolume.enabled (eq $volume.existingClaim $otherVolume.existingClaim) }}
{{- fail (printf "existingClaim %q is used by multiple directories; set subPath for every directory that uses the same existing PVC." $volume.existingClaim) }}
{{- end }}
{{- end }}
{{- end }}
{{- range $name, $volume := $volumes }}
{{- if and $volume.enabled $volume.existingClaim $volume.subPath }}
{{- range $otherName, $otherVolume := $volumes }}
{{- if and (ne $name $otherName) $otherVolume.enabled (eq $volume.existingClaim $otherVolume.existingClaim) (eq $volume.subPath $otherVolume.subPath) }}
{{- fail (printf "existingClaim %q uses subPath %q for multiple directories; each directory must use a distinct subPath." $volume.existingClaim $volume.subPath) }}
{{- end }}
{{- end }}
{{- end }}
{{- end }}
{{- end }}
{{- end }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Make shared-PVC migration explicit and safe.

Shared-PVC mode uses only persistence.claim settings. Existing per-directory size, storageClass, and accessMode values can be silently ignored. The migration procedure also permits copying active data and does not provide a safe way to prepopulate the chart-managed claim before the StatefulSet switches to it.

  • charts/openhab/templates/_helpers.tpl#L118-L149: reject legacy per-directory overrides that differ from supported migration defaults, or require explicit shared-claim settings before shared-PVC mode renders.
  • charts/openhab/UPGRADING.md#L63-L68: require a quiesced openHAB workload before copying data. Document a supported prepopulation path, such as a pre-provisioned shared existingClaim, before changing mounts.
📍 Affects 2 files
  • charts/openhab/templates/_helpers.tpl#L118-L149 (this comment)
  • charts/openhab/UPGRADING.md#L63-L68
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/openhab/templates/_helpers.tpl` around lines 118 - 149, Update
openhab.validatePersistence to validate shared-PVC mode: when persistence.claim
is enabled, reject differing legacy per-directory size, storageClass, or
accessMode overrides, or require explicit persistence.claim settings before
rendering. In charts/openhab/UPGRADING.md lines 63-68, require the openHAB
workload to be quiesced before copying data and document prepopulating the
chart-managed claim via a pre-provisioned shared existingClaim before switching
mounts.


{{- if .Values.persistence.userdata.enabled }}
userdata ({{ .Values.persistence.userdata.size }}): Runtime state, logs, JSONDB
userdata ({{ if .Values.persistence.claim.enabled }}shared PVC {{ .Values.persistence.claim.size }}{{ else }}{{ .Values.persistence.userdata.size }} dedicated PVC{{ end }}): Runtime state, logs, JSONDB

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Do not report configured sizes for existing PVCs.

The persistence.claim.enabled condition distinguishes shared mode from dedicated mode, but it does not distinguish generated PVCs from existing PVCs. As a result, Line 77 can display persistence.claim.size for a shared existing PVC, and Lines 86 and 95 can display per-directory sizes for dedicated existing PVCs. Those values may not describe the actual PVC capacity.

Use the resolved claim source for the label and size. Show a size only when Helm creates the PVC. Use distinct wording for generated shared claims, shared existing claims, and dedicated existing claims. Add render coverage for all three cases.

Also applies to: 86-86, 95-95

🧰 Tools
🪛 LanguageTool

[style] ~77-~77: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...sistence.claim.enabled }}shared PVC {{ .Values.persistence.claim.size }}{{ else }}{{ ....

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~77-~77: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ....persistence.claim.size }}{{ else }}{{ .Values.persistence.userdata.size }} dedicated ...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/openhab/templates/NOTES.txt` at line 77, Update the NOTES descriptions
for userdata, addons, and backups to use the resolved claim source rather than
only persistence.claim.enabled: distinguish generated shared claims, shared
existing claims, and dedicated existing claims, and omit configured sizes
whenever the PVC already exists. Add Helm render coverage covering all three
claim scenarios and verify the labels and size suppression for each.

@mberlofa

Copy link
Copy Markdown
Contributor

@drieks You're right — that command belongs to our maintainer tooling and is not available in this repository. Sorry for the confusion.

From the charts repository, you can run the public checks directly:

helm dependency build charts/openhab
helm lint --strict charts/openhab
helm template openhab-test charts/openhab
helm unittest charts/openhab

Pushing your changes will also run the repository CI. We'll handle the internal k3d validation on our side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:docs area:schema area:templates area:tests area:values chart:openhab Issues related to the openhab chart enhancement New feature or request size:XL type:feature Feature or enhancement change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants