fix(deps): Update third-party container images to latest stable versions (resolves #2046).#2050
fix(deps): Update third-party container images to latest stable versions (resolves #2046).#2050junhaoliao wants to merge 11 commits intoy-scope:mainfrom
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughUpdated container image tags and a Helm chart version across deployment manifests and a controller default: MySQL, MariaDB, RabbitMQ, Redis, MongoDB, and bitnami/kubectl image tags were changed. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tools/deployment/package-helm/templates/_helpers.tpl`:
- Line 370: The Helm template currently pins a non-existent image tag
("bitnami/kubectl:1.31"); update the image reference in the _helpers.tpl
template to a valid tag or digest (e.g., "bitnami/kubectl:latest" or a specific
SHA256 digest) so pods can be created successfully—replace image:
"bitnami/kubectl:1.31" with the chosen valid tag/digest and, if reproducibility
is required, prefer pinning the SHA256 digest instead of :latest.
In `@tools/deployment/package-helm/templates/queue-statefulset.yaml`:
- Line 24: Update the deployment test plan for the RabbitMQ image change to
"rabbitmq:4.2.4": verify there are no classic mirrored queues (or migrate to
quorum queues) by inspecting cluster/queue configuration, run the health check
`rabbitmq-diagnostics check_running` after startup, perform smoke tests with the
project's Celery version (Celery 5.6.2+)—start workers, publish and consume
messages, and exercise typical task payloads to detect AMQP frame negotiation
issues related to the increased default initial_frame_max (8192); if you hit
frame errors, either adjust RabbitMQ's initial_frame_max or configure
Celery/clients accordingly or revert the image until compatibility is confirmed.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (8)
components/clp-package-utils/clp_package_utils/controller.pytools/deployment/package-helm/Chart.yamltools/deployment/package-helm/templates/_helpers.tpltools/deployment/package-helm/templates/database-statefulset.yamltools/deployment/package-helm/templates/queue-statefulset.yamltools/deployment/package-helm/templates/redis-statefulset.yamltools/deployment/package-helm/templates/results-cache-statefulset.yamltools/deployment/package/docker-compose-all.yaml
| containers: | ||
| - name: "queue" | ||
| image: "rabbitmq:3.9.8" | ||
| image: "rabbitmq:4.2.4" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
RabbitMQ 4.0 4.2 breaking changes migration guide
💡 Result:
RabbitMQ 4.0 (from 3.13.x): key breaking changes + what to do
- Classic (mirrored) queue HA is removed in 4.0 → migrate to Quorum Queues or Streams (classic queues remain, but non-replicated). Plan a migration (often blue/green) and remove mirroring policies/args. [1]
- If you enabled Khepri on RabbitMQ 3.13.x, you cannot in-place upgrade to 4.x (you must migrate/blue-green to a fresh 4.x cluster). [2]
- Quorum queue behavior change (4.0): default delivery limit is now 20 → validate any workloads that rely on repeated redeliveries/retries. [3]
- Upgrade prerequisites: ensure required/stable feature flags are enabled before upgrading, and follow supported upgrade paths (e.g., 3.13.x → 4.0.x is supported). [2]
- Erlang/OTP compatibility: RabbitMQ 4.0.x requires Erlang/OTP ≥ 26.2 (and supports 27.x). [4]
RabbitMQ 4.2 (from 4.0/4.1 or 3.13): breaking changes to check
From the 4.2 release notes / compatibility notes:
- AMQP 1.0 durability default: if a sending client omits the AMQP 1.0 header section, RabbitMQ 4.2 assumes
durable=false(per spec). AMQP 1.0 publishers should explicitly setdurable=truewhen they need durable messages. [5] - AMQP 0.9.1 Direct Reply-To +
mandatory: publishing replies withmandatory=truetoamq.rabbitmq.reply-to.*is treated as “routed” (nobasic.returnjust because the requester is gone). If you relied onbasic.returnfor RPC failure detection, adjust client logic. [5] - Config cleanup: very rarely used
*.cacertssettings were removed fromrabbitmq.conf(notcacertfile). Remove/replace if present. [5] - Erlang/OTP note for 4.2.x: still min Erlang/OTP 26.2, supports 27.x; Erlang 28 has caveats (notably with Khepri upgrades). [4]
Practical migration checklist (4.0 → 4.2, or 3.13 → 4.2)
- Inventory deprecated/removed features (especially mirrored classic queues) and migrate to quorum queues/streams. [1]
- If on 3.13 + Khepri enabled, plan blue/green migration, not in-place upgrade. [2]
- Confirm feature flags state and supported upgrade path for your current version. [2]
- Validate Erlang/OTP version meets the target series requirements. [4]
- If you use AMQP 1.0 or Direct Reply-To RPC, regression-test the 4.2 behavior changes above. [5]
Sources: What’s New in RabbitMQ 4.0 (mirroring removed) [1]; RabbitMQ 4.x upgrade guide (paths, feature flags, Khepri caveat) [2]; RabbitMQ blog on quorum queues in 4.0 (delivery limit default 20) [3]; Erlang/RabbitMQ compatibility matrix [4]; RabbitMQ 4.2.0 release notes / breaking changes section [5].
🌐 Web query:
Celery RabbitMQ 4.x compatibility support
💡 Result:
Celery 4.x uses the AMQP 0-9-1 client stack (via Kombu/py-amqp), so it’s generally compatible with RabbitMQ 4.x as a broker because RabbitMQ 4.x continues to support AMQP 0-9-1 (and also adds native AMQP 1.0 support, which Celery 4.x does not use) [3][4].
The main RabbitMQ 4.x compatibility pitfall to watch is frame-size/handshake changes in RabbitMQ 4.1+:
- RabbitMQ’s pre-auth “initial frame max” is 8192 bytes by default in 4.x (
initial_frame_max) [2]. - RabbitMQ 4.1 notes that clients that override
frame_maxmust use ≥ 8192, and some older clients with low defaults needed upgrades [1]. (If your Celery/Kombu/py-amqp stack is old or pinned, this is where issues can surface.)
Practical guidance:
- If you can, upgrade Celery (4.x is tied to very old Python versions) [4].
- If you must stay on Celery 4.x, ensure your Kombu/py-amqp dependencies aren’t extremely old, and smoke-test worker connection + publish/consume against your exact RabbitMQ 4.x version (especially 4.1+), watching for handshake/frame negotiation errors [1][2].
🏁 Script executed:
# Check if there are any queue configurations or celery-related settings in the codebase
fd -e yaml -e yml -e py | head -20 | xargs rg -l "celery|queue|mirroring" 2>/dev/null | head -20Repository: y-scope/clp
Length of output: 173
🏁 Script executed:
# Search for any explicit queue configuration in helm templates
fd -e yaml -e yml . tools/deployment/package-helm/templates/ | xargs rg -i "queue|mirror|policy" 2>/dev/nullRepository: y-scope/clp
Length of output: 5426
🏁 Script executed:
# Read the queue-statefulset.yaml to see full configuration
cat -n tools/deployment/package-helm/templates/queue-statefulset.yaml | head -80Repository: y-scope/clp
Length of output: 2061
🏁 Script executed:
# Search for celery and kombu versions in requirements/setup files
fd -e txt -e py -e yaml . | xargs rg -i "celery|kombu|py.amqp" 2>/dev/null | grep -i "version\|=="Repository: y-scope/clp
Length of output: 219
🏁 Script executed:
# Check queue configuration and health check details
cat -n tools/deployment/package-helm/templates/queue-statefulset.yaml | tail -50Repository: y-scope/clp
Length of output: 2006
🏁 Script executed:
# Search for celery version specifications in requirements files
fd -e txt -e cfg -e toml . | xargs rg "celery" -A 2 -B 2 2>/dev/null | head -40Repository: y-scope/clp
Length of output: 385
🏁 Script executed:
# Look for Python requirements or setup.py to find exact versions
fd -type f \( -name "requirements*.txt" -o -name "setup.py" -o -name "pyproject.toml" -o -name "Pipfile" \)Repository: y-scope/clp
Length of output: 225
🏁 Script executed:
# Find requirements files
find . -name "requirements*.txt" -o -name "setup.py" -o -name "pyproject.toml" -o -name "Pipfile" 2>/dev/null | head -20Repository: y-scope/clp
Length of output: 410
🏁 Script executed:
# Check if there are any queue/mirroring policies in helm values or configuration
fd -e yaml -e yml . tools/deployment/package-helm/ | xargs rg -i "policy|mirroring|mirror" 2>/dev/nullRepository: y-scope/clp
Length of output: 2433
🌐 Web query:
rabbitmq-diagnostics check_running command RabbitMQ 4.x compatibility
💡 Result:
Yes—rabbitmq-diagnostics check_running is supported in RabbitMQ 4.x (it’s documented in the RabbitMQ 4.0 rabbitmq-diagnostics man page and referenced in the 4.1 monitoring/health-check guidance). It is therefore compatible to use as a health check with RabbitMQ 4.x. [1], [2]
What it does in 4.x:
- Fails (non‑zero exit code) if the RabbitMQ application is not running on the target node (e.g., if it was stopped via
rabbitmqctl stop_app, or is paused/stopped). [1], [2] - Common usage:
rabbitmq-diagnostics check_running[1]- Quiet mode for probes:
rabbitmq-diagnostics -q check_running[2] - Often paired with alarms check (recommended “stage 3” style check):
rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_local_alarms[2]
Sources:
[1] RabbitMQ 4.0 rabbitmq-diagnostics(8) man page (check_running)
[2] RabbitMQ 4.1 Monitoring guide (node health checks using check_running)
Test Celery 5.x with RabbitMQ 4.2.4 before deployment.
While upgrading from RabbitMQ 3.9.8 to 4.2.4, note that RabbitMQ 4.0 removed classic queue mirroring (requiring migration to quorum queues if used). However, no mirroring configuration is evident in this deployment. The health check command rabbitmq-diagnostics check_running is compatible with RabbitMQ 4.x.
Celery 5.6.2+ (as specified in the codebase) is compatible with RabbitMQ 4.x over AMQP 0-9-1. However, RabbitMQ 4.1+ changed the default initial_frame_max to 8192 bytes. Perform smoke testing (connect workers, publish/consume messages) to ensure no frame negotiation issues arise.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tools/deployment/package-helm/templates/queue-statefulset.yaml` at line 24,
Update the deployment test plan for the RabbitMQ image change to
"rabbitmq:4.2.4": verify there are no classic mirrored queues (or migrate to
quorum queues) by inspecting cluster/queue configuration, run the health check
`rabbitmq-diagnostics check_running` after startup, perform smoke tests with the
project's Celery version (Celery 5.6.2+)—start workers, publish and consume
messages, and exercise typical task payloads to detect AMQP frame negotiation
issues related to the increased default initial_frame_max (8192); if you hit
frame errors, either adjust RabbitMQ's initial_frame_max or configure
Celery/clients accordingly or revert the image until compatibility is confirmed.
hoophalab
left a comment
hoophalab
left a comment
There was a problem hiding this comment.
LGTM, though I cannot 100% sure there won't be issues in some edge cases.
Validations: compressed and searched logs in webui. This should involve all updated components.
There was a problem hiding this comment.
probably need to bump helm version
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tools/deployment/package-helm/templates/_helpers.tpl`:
- Line 385: The image reference currently pins to a mutable minor tag ("image:
\"bitnami/kubectl:1.31\""); replace it with the resolved immutable digest form
(e.g. "bitnami/kubectl:1.31@sha256:<digest>") to ensure reproducible
deployments. Resolve the digest in CI or locally (e.g. docker inspect or skopeo
inspect docker://bitnami/kubectl:1.31) and update the image string in the
template to include the `@sha256` digest.
🪄 Autofix (Beta)
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: ASSERTIVE
Plan: Pro
Run ID: 463b8ae9-c0ba-4383-8035-3bdf74b7450c
📒 Files selected for processing (4)
components/clp-package-utils/clp_package_utils/controller.pytools/deployment/package-helm/Chart.yamltools/deployment/package-helm/templates/_helpers.tpltools/deployment/package/docker-compose-all.yaml
2 participants
Description
Update all third-party container images used in the Helm chart, Docker Compose, and the Python
controller to their latest stable versions. Pin
bitnami/kubectl:latestto a specific version forreproducibility.
mariadb:10-jammymariadb:10.11.16mysqladmin(used by health checks), so staying on 10.x per issue guidance.mysql:8.0.23mysql:8.0.45mongo:7.0.1mongo:8.0.19rabbitmq:3.9.8rabbitmq:4.2.4redis:7.2.4redis:7.4.8bitnami/kubectl:latestbitnami/kubectl:1.31:latestis non-deterministicUpdated in three locations:
tools/deployment/package-helm/templates/):database-statefulset.yaml,results-cache-statefulset.yaml,queue-statefulset.yaml,redis-statefulset.yaml,_helpers.tpltools/deployment/package/docker-compose-all.yaml)components/clp-package-utils/clp_package_utils/controller.py): setsCLP_DB_CONTAINER_IMAGE_REFused by the Docker Compose database serviceChecklist
breaking change.
Validation performed
1. Build the CLP package
Task: Build the CLP package (including the Docker image) with the updated image references.
Command:
Output (last lines):
2. Start CLP and verify all services are healthy with updated images
Task: Start CLP via Docker Compose and confirm all third-party services pull the correct updated
images and pass their health checks.
Commands:
cd build/clp-package ./sbin/start-clp.shOutput (last line):
Verification — running container images and health status:
Explanation: All four updated third-party images are running and report
(healthy). Themysqladmin ping,rabbitmq-diagnostics check_running,redis-cli PING, andmongosh pinghealth checks all pass with the new versions.
3. Run a compression job
Task: Verify end-to-end compression pipeline (database, queue, Redis, MongoDB all participate).
Command:
./sbin/compress.sh --unstructured ~/samples/hive-24hr/Output:
Explanation: Compression completed successfully. The full pipeline — job submission via MariaDB,
task dispatch via RabbitMQ, result tracking via Redis, and metadata storage via MongoDB — functions
correctly with the updated images.
3. Run a compression job
Task: Verify end-to-end compression pipeline (database, queue, Redis, MongoDB all participate).
Command:
./sbin/compress.sh --unstructured ~/samples/hive-24hr/Output:
Explanation: Compression completed successfully. The full pipeline — job submission via MariaDB,
task dispatch via RabbitMQ, result tracking via Redis, and metadata storage via MongoDB — functions
correctly with the updated images.
4. Run a search query
Task: Verify the search pipeline (query scheduler, query worker, Redis, MongoDB) works with the
updated images.
Commands:
Output:
Explanation: Both wildcard and filtered searches return results from the archives compressed in
step 3. The query pipeline — job dispatch via RabbitMQ, task coordination via Redis, and result
storage via MongoDB — functions correctly with the updated images.
5. Verify Helm template rendering (MariaDB default)
Task: Confirm the Helm chart renders the correct updated image references.
Command:
Output:
The
image: >-multiline entry resolves tomariadb:10.11.16:6. Verify Helm template rendering (MySQL conditional)
Task: Confirm the MySQL path in
database-statefulset.yamlrenders the updated MySQL version.Command:
Output:
Explanation: Both the MariaDB (default) and MySQL conditional paths render the correct updated
image tags.
Summary by CodeRabbit