Post-2.4.0 follow-ups: ArtifactHub license, configurable helper images, Minikube guide fixes - #22
Draft
dmytro-landiak wants to merge 5 commits into
Draft
dmytro-landiak wants to merge 5 commits into
dmytro-landiak wants to merge 5 commits into
Conversation
The chart declared its license with a bare `licenses: Apache-2.0` key, which is not an Artifact Hub annotation, so Artifact Hub never picked it up — the package page showed no license at all (the API returned `license: null` for 2.1.0). Use the supported `artifacthub.io/license` annotation instead. The value must be a valid SPDX identifier, which Apache-2.0 is.
The chart hardcoded three image references in its templates: `thingsboard/toolbox:1.13.0` for the broker's `validate-db` init container, and `busybox:1.36` for the `wait-for-postgres` init container on both the install Pod and the pre-upgrade Job. Because they were not wired to values, there was no way to repoint them at a private registry or an air-gapped mirror — the chart always tried to pull them from Docker Hub. Expose them as `helperImages.toolbox` and `helperImages.busybox`, each with the same `repository` / `tag` shape already used by `tbmq.image`, and resolve them through two new template helpers. Also bump both to current releases: toolbox 1.13.0 -> 1.29.0 (1.13.0 was 16 releases behind) and busybox 1.36 -> 1.37.0 (the 1.36 tag is no longer rebuilt, so it carries unpatched base-image CVEs). Both are drop-in replacements: toolbox 1.29.0 has the same layout as 1.13.0 (bash, psql, and the script-runner.sh / psql-validator.sh scripts under WORKDIR /scripts) and the script contents are unchanged, and busybox only needs a shell and `nc`. Both were verified running as init containers against a live PostgreSQL 17 cluster.
…ke test Two fixes to the Minikube guide. The note on the install Pod claimed the delete policy is `hook-succeeded,hook-failed`, so Helm would remove the Pod "as soon as it succeeds (or fails)". The template actually sets `hook-succeeded,before-hook-creation`: a succeeded Pod is removed immediately, but a FAILED Pod is deliberately retained and only cleaned up just before the next hook run. That inverted the debugging advice — the guide told readers to race `kubectl logs -f` during install, when in the case that actually matters (a failed install) the Pod is still sitting there to inspect afterwards. Second, the guide stopped at logging into the UI, which only exercises the broker's HTTP port. TBMQ 2.4.0 enables the MQTT_BASIC authentication provider with an empty credential list (X.509, JWT, SCRAM and HTTP are disabled by default), so a freshly deployed broker refuses every MQTT client with CONNECTION_REFUSED_NOT_AUTHORIZED. Anyone following the guide and then pointing an MQTT client at the broker hit that with no explanation. Add a "Smoke-test MQTT" section that says so upfront, shows the exact client error and broker log lines, creates an MQTT_BASIC credential over the REST API, and round-trips a message with mosquitto_sub / mosquitto_pub. Token extraction uses sed so the guide adds no jq or python dependency.
2.1.0 is already published and immutable, so the license-annotation fix and the new `helperImages` values only reach Artifact Hub under a new chart version. Replace the `artifacthub.io/changes` entries with the ones describing 2.1.1, per Artifact Hub semantics (the annotation lists what changed in *this* version; 2.1.0's entries stay visible on the 2.1.0 package page). Note: this drops the TBMQ 2.4.0 Prometheus metrics-rename heads-up from the latest version's changelog. If that warning should stay visible on the newest package page, carry the entry forward here.
The MQTT smoke test added in the previous commit was wrong on its central premise. It claimed TBMQ 2.4.0 enables MQTT_BASIC with an empty credential list, so every client is refused until you create credentials. TBMQ actually creates a system credential at install time — `WS_SYSTEM_MQTT_CLIENT_CREDENTIALS_USERNAME` / "TBMQ WebSockets MQTT Credentials", username `tbmq_websockets_username`, with no password. It is defined in common/data BrokerConstants, so it exists in CE and PE alike, and TBMQ's own "Getting started" guides publish and subscribe with it directly. Verified against a live broker: a client passing `-u tbmq_websockets_username` and no password authenticates and round-trips a message. What is true is narrower: MQTT_BASIC is the only provider enabled by default, so a client sending no username at all is rejected with CONNECTION_REFUSED_NOT_AUTHORIZED. That is worth documenting, because it is the confusing case — but it is not a reason to make readers create a credential before they can test anything. Rewrite the section to use the built-in credential (no setup, no REST call), keep the rejection message as an explained aside, and demote creating your own credential to an optional subsection for when you want a password or narrower topic rules. Also add upstream's caveat about passing `-P` if the credential has been changed, and correct the matching artifacthub.io/changes entry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-ups found while auditing the TBMQ 2.4.0 chart release (chart 2.1.0 / app 2.4.0) against the published ArtifactHub package and the Minikube guide.
Opened as a draft because it carries a chart version bump — see Two decisions below. Merging this does not publish anything; packaging and the push to
helm.thingsboard.ioare separate steps.What the audit confirmed was already correct
No action needed on these, recording them so the release is traceable:
helm.thingsboard.io/tbmq, and the published tarball matchesmain(only Helm's key re-serialization differs; parsed YAML is identical).thingsboard-mqtt-broker.yml(469 vars) andtbmq-integration-executor.yml(93 vars): every one is still supported, and neither config has a single required-without-default${VAR}, so no new mandatory setting exists.REDIS_JEDIS_CLUSTER_TOPOLOGY_REFRESH_*is absent from 2.4.0 whileREDIS_LETTUCE_*remains. The IE is Kafka-only, matching the chart'senvFromwiring.kafka.strimzi.io/v1is served by Strimzi 0.50.0, and the shippedminikube-values.yaml/minikube-pe-values.yamlmatch the guide's inline YAML exactly.Changes
1. ArtifactHub showed no license (
fix)Chart.yamlused a barelicenses: Apache-2.0key, which is not an ArtifactHub annotation. The API returnedlicense: nullfor 2.1.0. Switched to the supportedartifacthub.io/license.2. Helper images were hardcoded and stale (
feat)Three image references were hardcoded in templates —
thingsboard/toolbox:1.13.0(brokervalidate-dbinit container) andbusybox:1.36(wait-for-postgreson the install Pod and pre-upgrade Job). Not being wired to values, they could not be repointed at a private registry or air-gapped mirror.Now exposed as
helperImages.toolbox/helperImages.busyboxusing the samerepository/tagshape astbmq.image, and bumped: toolbox 1.13.0 → 1.29.0 (was 16 releases behind), busybox 1.36 → 1.37.0 (the 1.36 tag is no longer rebuilt, so it carries unpatched base CVEs).Both bumps were checked rather than assumed: toolbox 1.29.0 has the same layout as 1.13.0 (
bash,psql, andscript-runner.sh/psql-validator.shunderWORKDIR /scripts) with byte-identical script contents.3. Minikube guide: wrong install-Pod delete policy (
docs)The guide said
hook-succeeded,hook-failed. The template setshook-succeeded,before-hook-creation— a failed install Pod is retained for inspection, not deleted. This inverted the debugging advice: readers were told to racekubectl logs -fduring install, when in the case that actually matters the Pod is still there afterwards.4. Minikube guide: no way to verify MQTT actually works (
docs)The guide ended at logging into the UI, which only exercises the HTTP port. Added a
Smoke-test MQTTsection that publishes and subscribes through the broker.It uses the credential TBMQ creates at install —
tbmq_websockets_username("TBMQ WebSockets MQTT Credentials"), defined incommon/dataBrokerConstantsso it exists in CE and PE alike, with no password. That needs no setup and matches what TBMQ's own "Getting started" guides use.The section also explains the genuinely confusing case:
MQTT_BASICis the only auth provider enabled by default (X.509,JWT,SCRAM,HTTPoff), so a client sending no username at all is rejected withCONNECTION_REFUSED_NOT_AUTHORIZED. Creating your own credential over the REST API is kept as an optional subsection for when you want a password or narrower topic rules.Verification
Full Minikube guide run on a clean cluster (k8s v1.32.0): PGO 6.0.1 → PostgreSQL 17.9, Strimzi 0.50.0 → 3-node KRaft Kafka 4.0.0, Valkey 0.9.3. Steps 1–4 all worked verbatim on the unmodified chart first.
Then the release was wiped, the broker PVC deleted, the database dropped and recreated, and the modified chart installed from scratch:
tbmq-cluster-2.1.1/ app 2.4.0, both pods Ready, PVC Bound 1Githingsboard/toolbox:1.29.0, exit 0 — its retry logic behaved correctly, failing the first schema probe against the empty DB and succeeding once the install Pod populated itbusybox:1.36on the old install,busybox:1.37.0on the new onetb_schema_settings→2004000 | CE, 20 tables-u tbmq_websockets_usernamewith no password round-trippedtbmq/demo/hello hello from minikubeat QoS 1ERRORlines in the broker loghelm lintclean on CE, PE, minikube-CE and minikube-PE;helm packageproduces a valid 2.1.1 tarball--set helperImages.toolbox.repository=registry.internal/mirror/toolboxrenders correctly on all four paths, including the pre-upgrade Job under--is-upgradeStep 5 (CE → PE migration) — also verified
Run against a QA license server with a real PE license. This exercises the pre-upgrade Job, which is one of the two places the new
busyboximage is used:tbmq-upgrade-2ran with init containerbusybox:1.37.0, main containerthingsboard/tbmq-pe-node:2.4.0PE,UPGRADE_TB=true,FROM_VERSION=ce— completed 1/1Upgrading TBMQ from version CE to PE ...→Upgrade finished successfully!→Loading system data for PE...tb_schema_settings→2004000 | PEtbmq-pe-node:2.4.0PE/tbmq-pe-integration-executor:2.4.0PEExecuted activateInstance method,Initialized ThingsBoard License Client with instanceId [...], plan data returned/data/tbmq-instance-license-tbmq-tbmq-node-0.data, exactly the path the chart documentsERRORlines in the PE broker log; pre-existing MQTT credentials survived the migrationNOTES.txtcorrectly reportedEdition: PE (Professional)Two decisions for the reviewer
artifacthub.io/changesnow describes 2.1.1, which means the TBMQ 2.4.0 Prometheus metrics-rename warning no longer appears on the latest package page (it remains on 2.1.0's). It is also not intbmq/README.md, whose newest upgrade section is still chart 1.x → 2.0.0. Worth carrying that entry forward, and/or adding a 2.3.0 → 2.4.0 upgrade section to the README.Known gaps left out of scope
.github/CI — nothing runshelm linton PRs.values.schema.json(has_values_schema: falseon ArtifactHub), no provenance signing (signed: false), noartifacthub.io/links, nokubeVersion.security_report_created_atis set) but produced an empty summary despitescanner_disabled: false— worth a look.