From 51e97685341733165425c068d7c15f430196cd86 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 25 Aug 2026 13:24:56 +0530 Subject: [PATCH 1/8] feat: ship RabbitMQ 4.2.9 instead of end-of-life 3.13.6 RabbitMQ 3.x is end-of-life and no longer receives security updates, so both charts now default to rabbitmq:4.2.9-management-alpine. 4.2 and not 4.3 deliberately: RabbitMQ does not support a direct 3.13 -> 4.3 upgrade (see the version upgradability table), and 4.2 is the supported hop from 3.13. Jumping this default straight to 4.3 would break in-place upgrades for every existing self-host install. A later release moves to 4.3, once installs have landed on 4.2. Two further things break on 4.3 but not on 4.2, which is the other reason to stage it: Celery's control/event queues are declared transient and non-exclusive, which 4.3 denies (fixed application-side in plane-ee by CELERY_CONTROL_QUEUE_EXCLUSIVE / CELERY_EVENT_QUEUE_EXCLUSIVE), and x-consumer-timeout is rejected on classic queues. Both READMEs gain an "Upgrading RabbitMQ from 3.13 to 4.2" section, because a chart upgrade restarts the broker against the existing volume and RabbitMQ requires all stable feature flags to be enabled BEFORE a major upgrade -- without that the 4.2 node refuses to start. It also records that khepri_db must stay disabled, that downgrades do not work, and that an externally managed broker is upgraded on the provider side. Verified on a live 3.13.6 -> 4.2.9 in-place upgrade of a full Plane deployment carrying pre-existing 3.x-era queues: every consumer reattached, queue arguments and durable messages survived, and no service logged a single AMQP error. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/Chart.yaml | 2 +- charts/plane-ce/README.md | 28 ++++++++++++++++++++++++++- charts/plane-ce/questions.yml | 2 +- charts/plane-ce/values.yaml | 2 +- charts/plane-enterprise/Chart.yaml | 2 +- charts/plane-enterprise/README.md | 28 ++++++++++++++++++++++++++- charts/plane-enterprise/questions.yml | 2 +- charts/plane-enterprise/values.yaml | 2 +- 8 files changed, 60 insertions(+), 8 deletions(-) diff --git a/charts/plane-ce/Chart.yaml b/charts/plane-ce/Chart.yaml index eedd48e..32a1268 100644 --- a/charts/plane-ce/Chart.yaml +++ b/charts/plane-ce/Chart.yaml @@ -5,7 +5,7 @@ description: Meet Plane. An open-source software development tool to manage issu type: application -version: 1.8.0 +version: 1.9.0 appVersion: "1.4.1" home: https://plane.so diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index dc531a1..252595e 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -21,6 +21,32 @@ helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace ``` +## Upgrading RabbitMQ from 3.13 to 4.2 + +This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of-life and no longer receives security updates. + +**If you are upgrading an existing install with `rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. + +```bash +# 1. While still on 3.13, enable every stable feature flag. +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all + +# 2. Confirm nothing stable is left disabled. Only `khepri_db` should remain, +# and it MUST stay disabled -- a 3.13 node with Khepri enabled cannot be +# upgraded to 4.x at all and needs a blue-green migration instead. +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl list_feature_flags + +# 3. Now run the chart upgrade, then confirm the broker came back. +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl status | grep 'RabbitMQ version' +``` + +Notes: + +- **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. +- **Downgrades do not work.** A 4.x node will not start on a data directory it has already upgraded, so keep a volume snapshot if you need a way back. +- **No queue changes are required.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. +- **Using an external broker?** If `rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed broker (Amazon MQ, CloudAMQP), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. + ## Installing Plane 1. Open Terminal or any other command-line app that has access to Kubernetes tools on your local system. @@ -210,7 +236,7 @@ The default value is `"traefik"`. If you previously relied on the implicit defau | Setting | Default | Required | Description | | ------------------------------ | :-------------------------------: | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | rabbitmq.local_setup | true | | Plane uses `rabbitmq` as message queuing system. This can be hosted within kubernetes as part of helm chart deployment or can be used as hosted service remotely (e.g. aws mq or similar services). Set this to `true` when you choose to setup stateful deployment of `rabbitmq`. Mark it as `false` when using a remotely hosted service | -| rabbitmq.image | rabbitmq:3.13.6-management-alpine | | Using this key, user must provide the docker image name to setup the stateful deployment of `rabbitmq`. (must be set when `rabbitmq.local_setup=true`) | +| rabbitmq.image | rabbitmq:4.2.9-management-alpine | | Using this key, user must provide the docker image name to setup the stateful deployment of `rabbitmq`. (must be set when `rabbitmq.local_setup=true`) | | rabbitmq.pullPolicy | IfNotPresent | | Using this key, user can set the pull policy for the stateful deployment of `rabbitmq`. (must be set when `rabbitmq.local_setup=true`) | | rabbitmq.servicePort | 5672 | | This key sets the default port number to be used while setting up stateful deployment of `rabbitmq`. | | rabbitmq.managementPort | 15672 | | This key sets the default management port number to be used while setting up stateful deployment of `rabbitmq`. | diff --git a/charts/plane-ce/questions.yml b/charts/plane-ce/questions.yml index 77ee6fc..88efc7d 100644 --- a/charts/plane-ce/questions.yml +++ b/charts/plane-ce/questions.yml @@ -407,7 +407,7 @@ questions: - variable: rabbitmq.image label: "Docker Image" type: string - default: "rabbitmq:3.13.6-management-alpine" + default: "rabbitmq:4.2.9-management-alpine" show_if: "rabbitmq.local_setup=true" - variable: rabbitmq.pullPolicy label: "Image Pull Policy" diff --git a/charts/plane-ce/values.yaml b/charts/plane-ce/values.yaml index 677bede..4b94330 100644 --- a/charts/plane-ce/values.yaml +++ b/charts/plane-ce/values.yaml @@ -91,7 +91,7 @@ postgres: rabbitmq: local_setup: true - image: rabbitmq:3.13.6-management-alpine + image: rabbitmq:4.2.9-management-alpine pullPolicy: IfNotPresent servicePort: 5672 managementPort: 15672 diff --git a/charts/plane-enterprise/Chart.yaml b/charts/plane-enterprise/Chart.yaml index 5db1386..cf7c9f4 100644 --- a/charts/plane-enterprise/Chart.yaml +++ b/charts/plane-enterprise/Chart.yaml @@ -5,7 +5,7 @@ description: Meet Plane. An Enterprise software development tool to manage issue type: application -version: 3.5.8 +version: 3.6.0 appVersion: "3.1.4" home: https://plane.so/ diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index a2a9bd5..2f24b6c 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -473,6 +473,32 @@ ingress: entryPoints: ['websecure'] ``` +## Upgrading RabbitMQ from 3.13 to 4.2 + +This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of-life and no longer receives security updates. + +**If you are upgrading an existing install with `services.rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. + +```bash +# 1. While still on 3.13, enable every stable feature flag. +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all + +# 2. Confirm nothing stable is left disabled. Only `khepri_db` should remain, +# and it MUST stay disabled -- a 3.13 node with Khepri enabled cannot be +# upgraded to 4.x at all and needs a blue-green migration instead. +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl list_feature_flags + +# 3. Now run the chart upgrade, then confirm the broker came back. +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl status | grep 'RabbitMQ version' +``` + +Notes: + +- **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. +- **Downgrades do not work.** A 4.x node will not start on a data directory it has already upgraded, so keep a volume snapshot if you need a way back. +- **No queue changes are required.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. +- **Using an external broker?** If `services.rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed broker (Amazon MQ, CloudAMQP), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. + ## Installing Plane 1. Open Terminal or any other command-line app that has access to Kubernetes tools on your local system. @@ -753,7 +779,7 @@ the bundled datastores off. Three things to know before you use it: | Setting | Default | Required | Description | | --------------------------------------- | :-------------------------------: | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | services.rabbitmq.local_setup | true | | Plane uses `rabbitmq` as message queuing system. This can be hosted within kubernetes as part of helm chart deployment or can be used as hosted service remotely (e.g. aws mq or similar services). Set this to `true` when you choose to setup stateful deployment of `rabbitmq`. Mark it as `false` when using a remotely hosted service | -| services.rabbitmq.image | rabbitmq:3.13.6-management-alpine | | Using this key, user must provide the docker image name to setup the stateful deployment of `rabbitmq`. (must be set when `services.rabbitmq.local_setup=true`) | +| services.rabbitmq.image | rabbitmq:4.2.9-management-alpine | | Using this key, user must provide the docker image name to setup the stateful deployment of `rabbitmq`. (must be set when `services.rabbitmq.local_setup=true`) | | services.rabbitmq.pullPolicy | IfNotPresent | | Using this key, user can set the pull policy for the stateful deployment of `rabbitmq`. (must be set when `services.rabbitmq.local_setup=true`) | | services.rabbitmq.servicePort | 5672 | | This key sets the default port number to be used while setting up stateful deployment of `rabbitmq`. | | services.rabbitmq.managementPort | 15672 | | This key sets the default management port number to be used while setting up stateful deployment of `rabbitmq`. | diff --git a/charts/plane-enterprise/questions.yml b/charts/plane-enterprise/questions.yml index e272675..889aa59 100644 --- a/charts/plane-enterprise/questions.yml +++ b/charts/plane-enterprise/questions.yml @@ -1542,7 +1542,7 @@ questions: - variable: services.rabbitmq.image label: "Docker Image" type: string - default: "rabbitmq:3.13.6-management-alpine" + default: "rabbitmq:4.2.9-management-alpine" show_if: "services.rabbitmq.local_setup=true" - variable: services.rabbitmq.pullPolicy label: "RabbitMQ Pull Policy" diff --git a/charts/plane-enterprise/values.yaml b/charts/plane-enterprise/values.yaml index a8be378..6cdf577 100644 --- a/charts/plane-enterprise/values.yaml +++ b/charts/plane-enterprise/values.yaml @@ -256,7 +256,7 @@ services: rabbitmq: local_setup: true - image: rabbitmq:3.13.6-management-alpine + image: rabbitmq:4.2.9-management-alpine servicePort: 5672 managementPort: 15672 volumeSize: 100Mi From 0d771549f5e41909430fc8ac892bfa8c464d5c79 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 11:55:35 +0530 Subject: [PATCH 2/8] docs(charts): note that the feature-flag pre-step is normally a no-op Measured on a fresh 3.13.7 node: every stable flag is enabled at birth, so the pre-upgrade step reports nothing to do on any install this chart created. Disabled stable flags only come from volumes carried across older series. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/README.md | 1 + charts/plane-enterprise/README.md | 1 + 2 files changed, 2 insertions(+) diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index 252595e..cb07ffd 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -42,6 +42,7 @@ kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl status | grep Notes: +- **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything — and note `enable_feature_flag all` covers stable flags only, so it will not turn Khepri on. - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. - **Downgrades do not work.** A 4.x node will not start on a data directory it has already upgraded, so keep a volume snapshot if you need a way back. - **No queue changes are required.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index 2f24b6c..d6b1d79 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -494,6 +494,7 @@ kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl status | grep Notes: +- **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything — and note `enable_feature_flag all` covers stable flags only, so it will not turn Khepri on. - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. - **Downgrades do not work.** A 4.x node will not start on a data directory it has already upgraded, so keep a volume snapshot if you need a way back. - **No queue changes are required.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. From 0ad5d059d2f88ab823fc0339c915302e65c8c432 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 12:05:05 +0530 Subject: [PATCH 3/8] docs(charts): correct the Khepri scoping and qualify the upgrade claims Addresses CodeRabbit review on #304, with the behaviour measured on real 3.13.7 and 4.2.9 brokers rather than inferred: - khepri_db is experimental on 3.13 but STABLE on 4.2, so the same `enable_feature_flag all` that is a safe no-op on 3.13 enables Khepri on 4.2. The previous note generalised the 3.13 measurement and was wrong for 4.2. Documented as a separate, snapshot-first step gated on moving to 4.3. - A 3.13.7 -> 4.2.9 in-place upgrade leaves khepri_db, rabbitmq_4.0.0/4.1.0/ 4.2.0 and rabbit_exchange_type_local_random disabled and keeps Mnesia. 4.3 requires those, so the hop needs an explicit step. - Rollback: a Khepri volume does not refuse 3.x loudly, it hangs in "Waiting for Khepri projections" with the port listening, so check_port_connectivity reports Ready while the broker never serves. Snapshot or blue-green. - Scope the "no queue changes" claim to the single-node broker this chart deploys, and add the classic-mirroring preflight for external/clustered brokers. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/README.md | 34 ++++++++++++++++++++++++------- charts/plane-enterprise/README.md | 34 ++++++++++++++++++++++++------- 2 files changed, 54 insertions(+), 14 deletions(-) diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index cb07ffd..86daead 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -31,9 +31,10 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of- # 1. While still on 3.13, enable every stable feature flag. kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all -# 2. Confirm nothing stable is left disabled. Only `khepri_db` should remain, -# and it MUST stay disabled -- a 3.13 node with Khepri enabled cannot be -# upgraded to 4.x at all and needs a blue-green migration instead. +# 2. Confirm nothing stable is left disabled. On 3.13 `khepri_db` is an +# EXPERIMENTAL flag, so step 1 does not touch it -- and it must stay +# disabled here: a 3.13 node with Khepri enabled cannot be upgraded to +# 4.x at all and needs a blue-green migration instead. kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl list_feature_flags # 3. Now run the chart upgrade, then confirm the broker came back. @@ -42,11 +43,30 @@ kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl status | grep Notes: -- **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything — and note `enable_feature_flag all` covers stable flags only, so it will not turn Khepri on. +- **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything. On 3.13 the command cannot turn Khepri on, because `khepri_db` is *experimental* there — that is **not** true on 4.2, where the same flag is stable (see below). - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. -- **Downgrades do not work.** A 4.x node will not start on a data directory it has already upgraded, so keep a volume snapshot if you need a way back. -- **No queue changes are required.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. -- **Using an external broker?** If `rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed broker (Amazon MQ, CloudAMQP), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. +- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. It does not crash — it hangs in `Waiting for Khepri projections` with the AMQP port already listening, so the chart's `check_port_connectivity` readiness probe reports the pod **Ready** while the broker never serves a client. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume — not a chart rollback. +- **No queue changes are required for the broker this chart deploys.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. This holds because the chart runs a **single-node** broker, where classic queue mirroring — removed in 4.0 — cannot be in effect. Plane sets no `ha-mode` policy itself. +- **Using an external broker?** If `rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed or clustered broker (Amazon MQ, CloudAMQP, your own cluster), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. Check for mirrored classic queues first, because 4.0 removed mirroring and any still-mirrored queue silently loses its replicas: + + ```bash + rabbitmq-queues check_if_cluster_has_classic_queue_mirroring_policy + ``` + + If that reports a policy, migrate those queues to quorum queues (or do a blue-green migration) before upgrading. + +### Reaching 4.3 later: the 4.2 feature flags + +A node upgraded in place to 4.2 leaves the flags 4.2 introduced **disabled** — measured on a 3.13.7 → 4.2.9 upgrade: `khepri_db`, `rabbitmq_4.0.0`, `rabbitmq_4.1.0`, `rabbitmq_4.2.0` and `rabbit_exchange_type_local_random` were all disabled afterwards, and the node kept using Mnesia. RabbitMQ 4.3 requires them, so they have to be enabled before that hop. + +**Do this as a deliberate step once 4.2 has been running cleanly — not as part of the upgrade.** On 4.2 `khepri_db` is *stable*, so `enable_feature_flag all` enables it, and that is a one-way door: it converts the metadata store to Khepri and permanently removes the option of going back to 3.x on that volume (verified — a 3.13 node then hangs on Khepri projections indefinitely). Take a volume snapshot first. + +```bash +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl list_feature_flags +``` + +Until you run this the broker is fully supported on 4.2 and Plane works normally; the only thing you cannot do is upgrade to 4.3. ## Installing Plane diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index d6b1d79..212d5bc 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -483,9 +483,10 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of- # 1. While still on 3.13, enable every stable feature flag. kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all -# 2. Confirm nothing stable is left disabled. Only `khepri_db` should remain, -# and it MUST stay disabled -- a 3.13 node with Khepri enabled cannot be -# upgraded to 4.x at all and needs a blue-green migration instead. +# 2. Confirm nothing stable is left disabled. On 3.13 `khepri_db` is an +# EXPERIMENTAL flag, so step 1 does not touch it -- and it must stay +# disabled here: a 3.13 node with Khepri enabled cannot be upgraded to +# 4.x at all and needs a blue-green migration instead. kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl list_feature_flags # 3. Now run the chart upgrade, then confirm the broker came back. @@ -494,11 +495,30 @@ kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl status | grep Notes: -- **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything — and note `enable_feature_flag all` covers stable flags only, so it will not turn Khepri on. +- **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything. On 3.13 the command cannot turn Khepri on, because `khepri_db` is *experimental* there — that is **not** true on 4.2, where the same flag is stable (see below). - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. -- **Downgrades do not work.** A 4.x node will not start on a data directory it has already upgraded, so keep a volume snapshot if you need a way back. -- **No queue changes are required.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. -- **Using an external broker?** If `services.rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed broker (Amazon MQ, CloudAMQP), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. +- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. It does not crash — it hangs in `Waiting for Khepri projections` with the AMQP port already listening, so the chart's `check_port_connectivity` readiness probe reports the pod **Ready** while the broker never serves a client. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume — not a chart rollback. +- **No queue changes are required for the broker this chart deploys.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. This holds because the chart runs a **single-node** broker, where classic queue mirroring — removed in 4.0 — cannot be in effect. Plane sets no `ha-mode` policy itself. +- **Using an external broker?** If `services.rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed or clustered broker (Amazon MQ, CloudAMQP, your own cluster), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. Check for mirrored classic queues first, because 4.0 removed mirroring and any still-mirrored queue silently loses its replicas: + + ```bash + rabbitmq-queues check_if_cluster_has_classic_queue_mirroring_policy + ``` + + If that reports a policy, migrate those queues to quorum queues (or do a blue-green migration) before upgrading. + +### Reaching 4.3 later: the 4.2 feature flags + +A node upgraded in place to 4.2 leaves the flags 4.2 introduced **disabled** — measured on a 3.13.7 → 4.2.9 upgrade: `khepri_db`, `rabbitmq_4.0.0`, `rabbitmq_4.1.0`, `rabbitmq_4.2.0` and `rabbit_exchange_type_local_random` were all disabled afterwards, and the node kept using Mnesia. RabbitMQ 4.3 requires them, so they have to be enabled before that hop. + +**Do this as a deliberate step once 4.2 has been running cleanly — not as part of the upgrade.** On 4.2 `khepri_db` is *stable*, so `enable_feature_flag all` enables it, and that is a one-way door: it converts the metadata store to Khepri and permanently removes the option of going back to 3.x on that volume (verified — a 3.13 node then hangs on Khepri projections indefinitely). Take a volume snapshot first. + +```bash +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all +kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl list_feature_flags +``` + +Until you run this the broker is fully supported on 4.2 and Plane works normally; the only thing you cannot do is upgrade to 4.3. ## Installing Plane From 44242621b193e3ad3331cdc63f465bc5e3ec39c5 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 12:16:45 +0530 Subject: [PATCH 4/8] fix(charts): make the RabbitMQ readiness probe react to a wedged broker The probe tolerated 50 failures at 30s intervals -- up to 25 minutes during which a broker that has stopped serving stays in the Service. plane-ce shipped no probe at all, so its broker was Ready from container start onwards. Both charts now run `check_running && check_port_connectivity` every 15s with failureThreshold 3, so a broker that boots but never finishes is out of the Service in ~45s. check_running is the boot-completion check, which is the condition that actually fails here. Measured against real brokers: healthy 4.2.9 PASS (535ms, timeoutSeconds is 10) healthy 4.2.9 + khepri_db PASS 3.13 on a Khepri volume FAIL exit 69 (container never exits) fresh boot, t=2s FAIL -> Ready by t=5s, no flapping No liveness or startup probe on purpose: a Khepri-wedged node is not restart-recoverable, so restarting it would only trade a NotReady pod for a crashloop, and a slow first boot must not be killed. Staying NotReady while booting is correct and harmless -- the clients reconnect. Worth noting for anyone reusing these commands: `rabbitmq-diagnostics ping` PASSES against a node stuck mid-boot, because the runtime is alive even when the broker is not. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/README.md | 3 ++- .../templates/workloads/rabbitmq.stateful.yaml | 10 ++++++++++ charts/plane-enterprise/README.md | 3 ++- .../templates/workloads/rabbitmq.stateful.yaml | 13 ++++++++----- 4 files changed, 22 insertions(+), 7 deletions(-) diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index 86daead..b0a1135 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -45,7 +45,8 @@ Notes: - **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything. On 3.13 the command cannot turn Khepri on, because `khepri_db` is *experimental* there — that is **not** true on 4.2, where the same flag is stable (see below). - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. -- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. It does not crash — it hangs in `Waiting for Khepri projections` with the AMQP port already listening, so the chart's `check_port_connectivity` readiness probe reports the pod **Ready** while the broker never serves a client. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume — not a chart rollback. +- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. The failure mode is the awkward one: the container does **not** exit. It sits in `Waiting for Khepri projections` indefinitely, so there is no CrashLoopBackOff to alert on — only a pod that never becomes Ready. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume, not a chart rollback. +- **The broker's readiness probe checks that it is actually serving.** It runs `rabbitmq-diagnostics check_running` (the app is booted, not merely listening) followed by `check_port_connectivity`, every 15s with a `failureThreshold` of 3 — so a broker that boots but never finishes leaves the pod NotReady within ~45s and is taken out of the Service. Note that `rabbitmq-diagnostics ping` is **not** sufficient here: it passes against a node stuck mid-boot, because the runtime is alive even though the broker is not. - **No queue changes are required for the broker this chart deploys.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. This holds because the chart runs a **single-node** broker, where classic queue mirroring — removed in 4.0 — cannot be in effect. Plane sets no `ha-mode` policy itself. - **Using an external broker?** If `rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed or clustered broker (Amazon MQ, CloudAMQP, your own cluster), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. Check for mirrored classic queues first, because 4.0 removed mirroring and any still-mirrored queue silently loses its replicas: diff --git a/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml b/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml index f770fdf..cc82e39 100644 --- a/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml +++ b/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml @@ -57,6 +57,16 @@ spec: - mountPath: /var/lib/rabbitmq name: pvc-{{ .Release.Name }}-rabbitmq-vol subPath: '' + readinessProbe: + exec: + command: + - sh + - -c + - rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_port_connectivity + initialDelaySeconds: 10 + periodSeconds: 15 + timeoutSeconds: 10 + failureThreshold: 3 {{- include "plane.podScheduling" .Values.rabbitmq }} serviceAccount: {{ include "plane.serviceAccountName" . }} serviceAccountName: {{ include "plane.serviceAccountName" . }} diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index 212d5bc..d230abd 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -497,7 +497,8 @@ Notes: - **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything. On 3.13 the command cannot turn Khepri on, because `khepri_db` is *experimental* there — that is **not** true on 4.2, where the same flag is stable (see below). - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. -- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. It does not crash — it hangs in `Waiting for Khepri projections` with the AMQP port already listening, so the chart's `check_port_connectivity` readiness probe reports the pod **Ready** while the broker never serves a client. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume — not a chart rollback. +- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. The failure mode is the awkward one: the container does **not** exit. It sits in `Waiting for Khepri projections` indefinitely, so there is no CrashLoopBackOff to alert on — only a pod that never becomes Ready. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume, not a chart rollback. +- **The broker's readiness probe checks that it is actually serving.** It runs `rabbitmq-diagnostics check_running` (the app is booted, not merely listening) followed by `check_port_connectivity`, every 15s with a `failureThreshold` of 3 — so a broker that boots but never finishes leaves the pod NotReady within ~45s and is taken out of the Service. Note that `rabbitmq-diagnostics ping` is **not** sufficient here: it passes against a node stuck mid-boot, because the runtime is alive even though the broker is not. - **No queue changes are required for the broker this chart deploys.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. This holds because the chart runs a **single-node** broker, where classic queue mirroring — removed in 4.0 — cannot be in effect. Plane sets no `ha-mode` policy itself. - **Using an external broker?** If `services.rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed or clustered broker (Amazon MQ, CloudAMQP, your own cluster), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. Check for mirrored classic queues first, because 4.0 removed mirroring and any still-mirrored queue silently loses its replicas: diff --git a/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml b/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml index a333a1e..d80beff 100644 --- a/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml +++ b/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml @@ -63,11 +63,14 @@ spec: subPath: '' readinessProbe: exec: - command: ["rabbitmq-diagnostics", "check_port_connectivity"] - initialDelaySeconds: 5 - periodSeconds: 30 - timeoutSeconds: 30 - failureThreshold: 50 + command: + - sh + - -c + - rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_port_connectivity + initialDelaySeconds: 10 + periodSeconds: 15 + timeoutSeconds: 10 + failureThreshold: 3 serviceAccount: {{ .Release.Name }}-srv-account serviceAccountName: {{ .Release.Name }}-srv-account volumeClaimTemplates: From 6a8d0fe68b32a16ad7cd8f5842aeaf8fc24f197f Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 12:33:34 +0530 Subject: [PATCH 5/8] docs(charts): state that the RabbitMQ upgrade is one-way and needs a snapshot Measured a 3.13.7 -> 4.2.9 -> 3.13.7 round trip with no feature flags enabled: the 4.2.9 node kept Mnesia, left khepri_db disabled and wrote no Khepri directories, yet 3.13.7 would not boot the volume again. The earlier note blamed khepri_db for this, which understated it -- booting 4.2 at all is the point of no return, and helm rollback does not undo a data-directory change. Snapshot is now step 0 of the runbook rather than a footnote. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/README.md | 7 +++++-- charts/plane-enterprise/README.md | 7 +++++-- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index b0a1135..725aab2 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -28,6 +28,9 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of- **If you are upgrading an existing install with `rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. ```bash +# 0. Snapshot the RabbitMQ volume. This upgrade cannot be reversed and +# `helm rollback` will not undo it -- see the notes below. + # 1. While still on 3.13, enable every stable feature flag. kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all @@ -45,7 +48,7 @@ Notes: - **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything. On 3.13 the command cannot turn Khepri on, because `khepri_db` is *experimental* there — that is **not** true on 4.2, where the same flag is stable (see below). - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. -- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. The failure mode is the awkward one: the container does **not** exit. It sits in `Waiting for Khepri projections` indefinitely, so there is no CrashLoopBackOff to alert on — only a pod that never becomes Ready. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume, not a chart rollback. +- **This upgrade is one-way. Snapshot the volume first.** Once a 4.2 node has started on a data directory, 3.13 cannot start on it again — and this is **not** conditional on enabling `khepri_db`. Measured: after a 3.13.7 → 4.2.9 upgrade the node still reported `khepri_db` *disabled* and was still using Mnesia, with no Khepri directories on disk, and 3.13.7 still refused to come back up. The failure mode is the awkward one — the container does **not** exit, it sits in `Waiting for Khepri projections` indefinitely, so there is no CrashLoopBackOff to alert on, only a pod that never becomes Ready. A `helm rollback` will not save you, because the data directory is what changed. Your only way back is a **pre-upgrade volume snapshot**, or a blue-green migration onto a fresh volume. - **The broker's readiness probe checks that it is actually serving.** It runs `rabbitmq-diagnostics check_running` (the app is booted, not merely listening) followed by `check_port_connectivity`, every 15s with a `failureThreshold` of 3 — so a broker that boots but never finishes leaves the pod NotReady within ~45s and is taken out of the Service. Note that `rabbitmq-diagnostics ping` is **not** sufficient here: it passes against a node stuck mid-boot, because the runtime is alive even though the broker is not. - **No queue changes are required for the broker this chart deploys.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. This holds because the chart runs a **single-node** broker, where classic queue mirroring — removed in 4.0 — cannot be in effect. Plane sets no `ha-mode` policy itself. - **Using an external broker?** If `rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed or clustered broker (Amazon MQ, CloudAMQP, your own cluster), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. Check for mirrored classic queues first, because 4.0 removed mirroring and any still-mirrored queue silently loses its replicas: @@ -60,7 +63,7 @@ Notes: A node upgraded in place to 4.2 leaves the flags 4.2 introduced **disabled** — measured on a 3.13.7 → 4.2.9 upgrade: `khepri_db`, `rabbitmq_4.0.0`, `rabbitmq_4.1.0`, `rabbitmq_4.2.0` and `rabbit_exchange_type_local_random` were all disabled afterwards, and the node kept using Mnesia. RabbitMQ 4.3 requires them, so they have to be enabled before that hop. -**Do this as a deliberate step once 4.2 has been running cleanly — not as part of the upgrade.** On 4.2 `khepri_db` is *stable*, so `enable_feature_flag all` enables it, and that is a one-way door: it converts the metadata store to Khepri and permanently removes the option of going back to 3.x on that volume (verified — a 3.13 node then hangs on Khepri projections indefinitely). Take a volume snapshot first. +**Do this as a deliberate step once 4.2 has been running cleanly — not as part of the upgrade.** On 4.2 `khepri_db` is *stable*, so `enable_feature_flag all` enables it, which converts the metadata store from Mnesia to Khepri. That conversion cannot be undone within 4.x either, so take a fresh volume snapshot before running it. (The route back to 3.13 is already gone by this point — see the one-way note above.) ```bash kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index d230abd..c6ac94f 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -480,6 +480,9 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of- **If you are upgrading an existing install with `services.rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. ```bash +# 0. Snapshot the RabbitMQ volume. This upgrade cannot be reversed and +# `helm rollback` will not undo it -- see the notes below. + # 1. While still on 3.13, enable every stable feature flag. kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all @@ -497,7 +500,7 @@ Notes: - **Step 1 will normally report nothing to do.** A node whose data directory was created by 3.13 enables every stable flag at birth (measured on a fresh 3.13.7: all stable flags enabled, only experimental `khepri_db` disabled), which is the case for any install this chart created. Disabled stable flags come from a volume carried across older series. Run it to confirm, not to change anything. On 3.13 the command cannot turn Khepri on, because `khepri_db` is *experimental* there — that is **not** true on 4.2, where the same flag is stable (see below). - **Do not jump straight to 4.3.** RabbitMQ does not support a direct 3.13 → 4.3 upgrade ([version upgradability](https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability)); 4.2 is the supported hop, and a later chart release will move to 4.3. Two further things break on 4.3 but not on 4.2: Celery's control/event queues (fixed in the application by `CELERY_CONTROL_QUEUE_EXCLUSIVE` / `CELERY_EVENT_QUEUE_EXCLUSIVE`), and `x-consumer-timeout` on classic queues. -- **Downgrades do not work, and they fail quietly.** RabbitMQ does not support downgrades at all; once 4.2 has enabled `khepri_db` the metadata store is converted and 3.x can never read that volume again. The failure mode is the awkward one: the container does **not** exit. It sits in `Waiting for Khepri projections` indefinitely, so there is no CrashLoopBackOff to alert on — only a pod that never becomes Ready. Your way back is a **pre-upgrade volume snapshot** or a blue-green migration onto a fresh volume, not a chart rollback. +- **This upgrade is one-way. Snapshot the volume first.** Once a 4.2 node has started on a data directory, 3.13 cannot start on it again — and this is **not** conditional on enabling `khepri_db`. Measured: after a 3.13.7 → 4.2.9 upgrade the node still reported `khepri_db` *disabled* and was still using Mnesia, with no Khepri directories on disk, and 3.13.7 still refused to come back up. The failure mode is the awkward one — the container does **not** exit, it sits in `Waiting for Khepri projections` indefinitely, so there is no CrashLoopBackOff to alert on, only a pod that never becomes Ready. A `helm rollback` will not save you, because the data directory is what changed. Your only way back is a **pre-upgrade volume snapshot**, or a blue-green migration onto a fresh volume. - **The broker's readiness probe checks that it is actually serving.** It runs `rabbitmq-diagnostics check_running` (the app is booted, not merely listening) followed by `check_port_connectivity`, every 15s with a `failureThreshold` of 3 — so a broker that boots but never finishes leaves the pod NotReady within ~45s and is taken out of the Service. Note that `rabbitmq-diagnostics ping` is **not** sufficient here: it passes against a node stuck mid-boot, because the runtime is alive even though the broker is not. - **No queue changes are required for the broker this chart deploys.** Existing queues keep their arguments and are re-declared as-is by the application; durable messages survive the restart. Verified end to end on a 3.13.6 → 4.2.9 in-place upgrade with pre-existing queues. This holds because the chart runs a **single-node** broker, where classic queue mirroring — removed in 4.0 — cannot be in effect. Plane sets no `ha-mode` policy itself. - **Using an external broker?** If `services.rabbitmq.local_setup: false` and you point `external_rabbitmq_url` at a managed or clustered broker (Amazon MQ, CloudAMQP, your own cluster), this chart does not manage its version — upgrade it on the provider side, following the same feature-flag prerequisite. Check for mirrored classic queues first, because 4.0 removed mirroring and any still-mirrored queue silently loses its replicas: @@ -512,7 +515,7 @@ Notes: A node upgraded in place to 4.2 leaves the flags 4.2 introduced **disabled** — measured on a 3.13.7 → 4.2.9 upgrade: `khepri_db`, `rabbitmq_4.0.0`, `rabbitmq_4.1.0`, `rabbitmq_4.2.0` and `rabbit_exchange_type_local_random` were all disabled afterwards, and the node kept using Mnesia. RabbitMQ 4.3 requires them, so they have to be enabled before that hop. -**Do this as a deliberate step once 4.2 has been running cleanly — not as part of the upgrade.** On 4.2 `khepri_db` is *stable*, so `enable_feature_flag all` enables it, and that is a one-way door: it converts the metadata store to Khepri and permanently removes the option of going back to 3.x on that volume (verified — a 3.13 node then hangs on Khepri projections indefinitely). Take a volume snapshot first. +**Do this as a deliberate step once 4.2 has been running cleanly — not as part of the upgrade.** On 4.2 `khepri_db` is *stable*, so `enable_feature_flag all` enables it, which converts the metadata store from Mnesia to Khepri. That conversion cannot be undone within 4.x either, so take a fresh volume snapshot before running it. (The route back to 3.13 is already gone by this point — see the one-way note above.) ```bash kubectl -n exec -rabbitmq-wl-0 -- rabbitmqctl enable_feature_flag all From 599bf2be19aea7f8220427fadd65f15eaee346c9 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 13:12:56 +0530 Subject: [PATCH 6/8] docs(charts): warn that RabbitMQ 4.2 requires the app-side amqplib bump Found by rehearsing this chart upgrade on a real deployment: taking the 4.2.9 default while the application stays on an older build drops the plane-exports, silo-api and silo-integrations consumers to 0, because 4.2 rejects a negotiated frame_max below 8192 and amqplib defaulted to 4096 until 0.10.6. Every pod still reports Ready, and Celery/pika are unaffected, so the failure is easy to miss entirely. This is not the 4.3-only issue it was previously believed to be, so the chart bump is coupled to the app version. Documented with the staging workaround of pinning the broker image while the app catches up. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/README.md | 11 +++++++++++ charts/plane-enterprise/README.md | 11 +++++++++++ 2 files changed, 22 insertions(+) diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index 725aab2..5bbb61d 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -25,6 +25,17 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of-life and no longer receives security updates. +> [!IMPORTANT] +> **Upgrade the application before, or together with, this chart — not after.** RabbitMQ 4.2 refuses any AMQP connection that negotiates +> a `frame_max` below 8192, and the `amqplib` client used by `silo`, `live` and `flux` defaulted to 4096 until 0.10.6. On a Plane build +> older than the one carrying that bump, moving the broker to 4.2.9 silently kills those consumers: the broker logs +> `failed to negotiate connection parameters: negotiated frame_max = 4096 is lower than the minimum allowed value (8192)`, integrations +> and exports stop, and **every pod still reports `Ready`**. Celery and the pika-based consumers are unaffected, which makes the failure +> easy to miss. Verified end to end — `plane-exports`, `silo-api` and `silo-integrations` all dropped to 0 consumers. +> +> If you must stage them, pin `rabbitmq.image` to `rabbitmq:3.13.6-management-alpine` when taking this chart, upgrade +> `planeVersion`, then remove the pin. + **If you are upgrading an existing install with `rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. ```bash diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index c6ac94f..0cb7f62 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -477,6 +477,17 @@ ingress: This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of-life and no longer receives security updates. +> [!IMPORTANT] +> **Upgrade the application before, or together with, this chart — not after.** RabbitMQ 4.2 refuses any AMQP connection that negotiates +> a `frame_max` below 8192, and the `amqplib` client used by `silo`, `live` and `flux` defaulted to 4096 until 0.10.6. On a Plane build +> older than the one carrying that bump, moving the broker to 4.2.9 silently kills those consumers: the broker logs +> `failed to negotiate connection parameters: negotiated frame_max = 4096 is lower than the minimum allowed value (8192)`, integrations +> and exports stop, and **every pod still reports `Ready`**. Celery and the pika-based consumers are unaffected, which makes the failure +> easy to miss. Verified end to end — `plane-exports`, `silo-api` and `silo-integrations` all dropped to 0 consumers. +> +> If you must stage them, pin `services.rabbitmq.image` to `rabbitmq:3.13.6-management-alpine` when taking this chart, upgrade +> `planeVersion`, then remove the pin. + **If you are upgrading an existing install with `services.rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. ```bash From af2f590da7e1dba6f0ee25027cf4f2a53123c2c9 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 13:34:13 +0530 Subject: [PATCH 7/8] feat(charts): refuse a 4.x broker under an app build that cannot reach it RabbitMQ 4.1+ rejects any connection negotiating a frame_max below 8192, and amqplib sent 4096 until 0.10.6. Deploying the 4.2.9 default under an older Plane build therefore drops the plane-exports, silo-api and silo-integrations consumers to zero -- integrations, imports and exports stop -- while every pod keeps reporting Ready. Verified on a real 3.13.6 -> 4.2.9 rehearsal. `rabbitmq.minPlaneVersion` is the floor; rendering fails with the three ways out rather than deploying a broken stack. It ships EMPTY (inert) and must be set to the first Plane release carrying the amqplib bump when these charts are released alongside that build. Scoped to only the unsafe combination. Verified 15 cases: it fires for a too-old release on a 4.x tag (including a registry:port image and a 4.3 tag), and stays quiet for a version at or above the floor, a broker pinned back to 3.13, an external broker, a branch tag, a prerelease, an untagged image, and an empty floor. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/README.md | 5 +++ charts/plane-ce/templates/_helpers.tpl | 45 +++++++++++++++++++ .../workloads/rabbitmq.stateful.yaml | 1 + charts/plane-ce/values.yaml | 6 +++ charts/plane-enterprise/README.md | 5 +++ .../plane-enterprise/templates/_helpers.tpl | 45 +++++++++++++++++++ .../workloads/rabbitmq.stateful.yaml | 1 + charts/plane-enterprise/values.yaml | 6 +++ 8 files changed, 114 insertions(+) diff --git a/charts/plane-ce/README.md b/charts/plane-ce/README.md index 5bbb61d..53ec91f 100644 --- a/charts/plane-ce/README.md +++ b/charts/plane-ce/README.md @@ -35,6 +35,11 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of- > > If you must stage them, pin `rabbitmq.image` to `rabbitmq:3.13.6-management-alpine` when taking this chart, upgrade > `planeVersion`, then remove the pin. +> +> **The chart enforces this.** `rabbitmq.minPlaneVersion` is the lowest `planeVersion` known to work with a 4.x +> broker; if you set a lower one while the chart is deploying a 4.x broker, rendering fails with an explanation rather than +> deploying a broken stack. Branch, preview and prerelease tags are allowed through — they cannot be compared here. Set it to +> an empty string to bypass the check. **If you are upgrading an existing install with `rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. diff --git a/charts/plane-ce/templates/_helpers.tpl b/charts/plane-ce/templates/_helpers.tpl index b887806..57f98e0 100644 --- a/charts/plane-ce/templates/_helpers.tpl +++ b/charts/plane-ce/templates/_helpers.tpl @@ -260,3 +260,48 @@ Caller must indent to the correct depth (env list items). {{- end }} {{- end }} {{- end -}} + +{{/* +Refuse to deploy a 4.x broker under an application build whose amqplib cannot +reach it. RabbitMQ >= 4.1 rejects any connection negotiating a frame_max below +8192 and amqplib defaulted to 4096 until 0.10.6, so an older Plane build loses +its silo/live consumers the moment the broker moves -- while every pod still +reports Ready. Measured on 4.2.9 and 4.3.5. + +Only fires when this chart manages the broker, the pinned tag is 4.x, and +planeVersion is an exact release. Branch, preview and prerelease tags are +allowed through: they are unresolvable here and blocking them would be wrong +more often than right. Set the floor to "" to bypass. +*/}} +{{- define "plane.validateBrokerClientCompat" -}} +{{- $rmq := .rabbitmq -}} +{{- $floor := $rmq.minPlaneVersion | default "" -}} +{{- if $floor -}} + {{- $tag := splitList ":" ($rmq.image | default "") | last -}} + {{- $major := regexFind "^[0-9]+" $tag -}} + {{- if and $major (ge (atoi $major) 4) -}} + {{- $pv := trimPrefix "v" (.planeVersion | default "") -}} + {{- if regexMatch "^[0-9]+\\.[0-9]+\\.[0-9]+$" $pv -}} + {{- if not (semverCompare (printf ">= %s" $floor) $pv) -}} + {{- $msg := list + (printf "RabbitMQ %s requires Plane >= %s, but planeVersion is %s." $tag $floor $pv) + "" + "RabbitMQ 4.1+ rejects connections negotiating frame_max below 8192, and the" + "amqplib client in that Plane build still negotiates 4096. Moving the broker" + "without moving the application drops the plane-exports, silo-api and" + "silo-integrations consumers to zero -- integrations, imports and exports" + "stop, while every pod continues to report Ready." + "" + "Pick one:" + (printf " 1. Set planeVersion to %s or newer (upgrade both together)." $floor) + " 2. Keep the broker on 3.13 for now: pin the rabbitmq image to" + " rabbitmq:3.13.6-management-alpine, upgrade planeVersion later," + " then remove the pin." + " 3. Bypass this check: set rabbitmq.minPlaneVersion to an empty string." + | join "\n" -}} + {{- fail (printf "\n\n%s\n" $msg) -}} + {{- end -}} + {{- end -}} + {{- end -}} +{{- end -}} +{{- end -}} diff --git a/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml b/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml index cc82e39..7543195 100644 --- a/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml +++ b/charts/plane-ce/templates/workloads/rabbitmq.stateful.yaml @@ -1,4 +1,5 @@ {{- if .Values.rabbitmq.local_setup }} +{{- include "plane.validateBrokerClientCompat" (dict "rabbitmq" .Values.rabbitmq "planeVersion" .Values.planeVersion) }} apiVersion: v1 kind: Service diff --git a/charts/plane-ce/values.yaml b/charts/plane-ce/values.yaml index 4b94330..44088cc 100644 --- a/charts/plane-ce/values.yaml +++ b/charts/plane-ce/values.yaml @@ -92,6 +92,12 @@ postgres: rabbitmq: local_setup: true image: rabbitmq:4.2.9-management-alpine + # Lowest planeVersion whose amqplib can reach a 4.x broker. RabbitMQ 4.1+ + # rejects a negotiated frame_max below 8192; amqplib sent 4096 until 0.10.6, + # so an older app silently loses its silo/live consumers when the broker + # moves. Rendering fails with an explanation instead. Set to '' to bypass. + # MUST be set to the first Plane release carrying the fix before release. + minPlaneVersion: '' pullPolicy: IfNotPresent servicePort: 5672 managementPort: 15672 diff --git a/charts/plane-enterprise/README.md b/charts/plane-enterprise/README.md index 0cb7f62..c2b5199 100644 --- a/charts/plane-enterprise/README.md +++ b/charts/plane-enterprise/README.md @@ -487,6 +487,11 @@ This chart now ships `rabbitmq:4.2.9-management-alpine`. RabbitMQ 3.x is end-of- > > If you must stage them, pin `services.rabbitmq.image` to `rabbitmq:3.13.6-management-alpine` when taking this chart, upgrade > `planeVersion`, then remove the pin. +> +> **The chart enforces this.** `services.rabbitmq.minPlaneVersion` is the lowest `planeVersion` known to work with a 4.x +> broker; if you set a lower one while the chart is deploying a 4.x broker, rendering fails with an explanation rather than +> deploying a broken stack. Branch, preview and prerelease tags are allowed through — they cannot be compared here. Set it to +> an empty string to bypass the check. **If you are upgrading an existing install with `services.rabbitmq.local_setup: true`, do this first.** The chart upgrade restarts the broker StatefulSet against the same volume, and RabbitMQ requires all stable feature flags to be enabled *before* a major upgrade — otherwise the 4.2 node refuses to start and your queues are unreachable until you roll back. diff --git a/charts/plane-enterprise/templates/_helpers.tpl b/charts/plane-enterprise/templates/_helpers.tpl index 29dad75..36b845c 100644 --- a/charts/plane-enterprise/templates/_helpers.tpl +++ b/charts/plane-enterprise/templates/_helpers.tpl @@ -403,3 +403,48 @@ Caller must nindent to the correct depth. {{- end -}} {{- end -}} {{- end -}} + +{{/* +Refuse to deploy a 4.x broker under an application build whose amqplib cannot +reach it. RabbitMQ >= 4.1 rejects any connection negotiating a frame_max below +8192 and amqplib defaulted to 4096 until 0.10.6, so an older Plane build loses +its silo/live consumers the moment the broker moves -- while every pod still +reports Ready. Measured on 4.2.9 and 4.3.5. + +Only fires when this chart manages the broker, the pinned tag is 4.x, and +planeVersion is an exact release. Branch, preview and prerelease tags are +allowed through: they are unresolvable here and blocking them would be wrong +more often than right. Set the floor to "" to bypass. +*/}} +{{- define "plane.validateBrokerClientCompat" -}} +{{- $rmq := .rabbitmq -}} +{{- $floor := $rmq.minPlaneVersion | default "" -}} +{{- if $floor -}} + {{- $tag := splitList ":" ($rmq.image | default "") | last -}} + {{- $major := regexFind "^[0-9]+" $tag -}} + {{- if and $major (ge (atoi $major) 4) -}} + {{- $pv := trimPrefix "v" (.planeVersion | default "") -}} + {{- if regexMatch "^[0-9]+\\.[0-9]+\\.[0-9]+$" $pv -}} + {{- if not (semverCompare (printf ">= %s" $floor) $pv) -}} + {{- $msg := list + (printf "RabbitMQ %s requires Plane >= %s, but planeVersion is %s." $tag $floor $pv) + "" + "RabbitMQ 4.1+ rejects connections negotiating frame_max below 8192, and the" + "amqplib client in that Plane build still negotiates 4096. Moving the broker" + "without moving the application drops the plane-exports, silo-api and" + "silo-integrations consumers to zero -- integrations, imports and exports" + "stop, while every pod continues to report Ready." + "" + "Pick one:" + (printf " 1. Set planeVersion to %s or newer (upgrade both together)." $floor) + " 2. Keep the broker on 3.13 for now: pin the rabbitmq image to" + " rabbitmq:3.13.6-management-alpine, upgrade planeVersion later," + " then remove the pin." + " 3. Bypass this check: set rabbitmq.minPlaneVersion to an empty string." + | join "\n" -}} + {{- fail (printf "\n\n%s\n" $msg) -}} + {{- end -}} + {{- end -}} + {{- end -}} +{{- end -}} +{{- end -}} diff --git a/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml b/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml index d80beff..df05c8d 100644 --- a/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml +++ b/charts/plane-enterprise/templates/workloads/rabbitmq.stateful.yaml @@ -1,4 +1,5 @@ {{- if .Values.services.rabbitmq.local_setup }} +{{- include "plane.validateBrokerClientCompat" (dict "rabbitmq" .Values.services.rabbitmq "planeVersion" .Values.planeVersion) }} apiVersion: v1 kind: Service diff --git a/charts/plane-enterprise/values.yaml b/charts/plane-enterprise/values.yaml index 6cdf577..cded75f 100644 --- a/charts/plane-enterprise/values.yaml +++ b/charts/plane-enterprise/values.yaml @@ -257,6 +257,12 @@ services: rabbitmq: local_setup: true image: rabbitmq:4.2.9-management-alpine + # Lowest planeVersion whose amqplib can reach a 4.x broker. RabbitMQ 4.1+ + # rejects a negotiated frame_max below 8192; amqplib sent 4096 until 0.10.6, + # so an older app silently loses its silo/live consumers when the broker + # moves. Rendering fails with an explanation instead. Set to '' to bypass. + # MUST be set to the first Plane release carrying the fix before release. + minPlaneVersion: '' servicePort: 5672 managementPort: 15672 volumeSize: 100Mi From e66b2de37f87b11cae478a766dabc3dd947f5b20 Mon Sep 17 00:00:00 2001 From: Pratapa Lakshmi Date: Tue, 8 Sep 2026 14:37:31 +0530 Subject: [PATCH 8/8] fix(charts): reject a malformed minPlaneVersion instead of breaking renders A floor that is not a version (a typo like "latest") reached semverCompare and raised an opaque template error, which blocks EVERY render of the chart -- a self-inflicted outage from one bad character in a release commit. It is now validated first and rejected with a message naming the bad value. Also sharpened the values comment: the floor is the first Plane release whose images carry the amqplib bump, normally the same value as that release's appVersion, and it stays pinned there -- raising it in later chart releases would block app versions that are actually fine. Verified 15 cases still behave, plus the two malformed-floor inputs. Co-Authored-By: Claude Opus 5 (1M context) --- charts/plane-ce/templates/_helpers.tpl | 3 +++ charts/plane-ce/values.yaml | 6 +++++- charts/plane-enterprise/templates/_helpers.tpl | 3 +++ charts/plane-enterprise/values.yaml | 6 +++++- 4 files changed, 16 insertions(+), 2 deletions(-) diff --git a/charts/plane-ce/templates/_helpers.tpl b/charts/plane-ce/templates/_helpers.tpl index 57f98e0..c64f94a 100644 --- a/charts/plane-ce/templates/_helpers.tpl +++ b/charts/plane-ce/templates/_helpers.tpl @@ -277,6 +277,9 @@ more often than right. Set the floor to "" to bypass. {{- $rmq := .rabbitmq -}} {{- $floor := $rmq.minPlaneVersion | default "" -}} {{- if $floor -}} + {{- if not (regexMatch "^v?[0-9]+(\\.[0-9]+){0,2}$" $floor) -}} + {{- fail (printf "\n\nrabbitmq.minPlaneVersion must be a version like \"3.2.0\", or \"\" to disable\nthe check. Got %q, which cannot be compared and would break every render.\n" $floor) -}} + {{- end -}} {{- $tag := splitList ":" ($rmq.image | default "") | last -}} {{- $major := regexFind "^[0-9]+" $tag -}} {{- if and $major (ge (atoi $major) 4) -}} diff --git a/charts/plane-ce/values.yaml b/charts/plane-ce/values.yaml index 44088cc..fcf2623 100644 --- a/charts/plane-ce/values.yaml +++ b/charts/plane-ce/values.yaml @@ -96,7 +96,11 @@ rabbitmq: # rejects a negotiated frame_max below 8192; amqplib sent 4096 until 0.10.6, # so an older app silently loses its silo/live consumers when the broker # moves. Rendering fails with an explanation instead. Set to '' to bypass. - # MUST be set to the first Plane release carrying the fix before release. + # MUST be set at release time to the FIRST Plane release whose images carry + # the amqplib bump -- normally the same value as Chart.yaml appVersion for + # that release. It then stays pinned there; do not raise it in later chart + # releases, or you will block app versions that are actually fine. A leading + # 'v' is accepted. minPlaneVersion: '' pullPolicy: IfNotPresent servicePort: 5672 diff --git a/charts/plane-enterprise/templates/_helpers.tpl b/charts/plane-enterprise/templates/_helpers.tpl index 36b845c..a38a0d4 100644 --- a/charts/plane-enterprise/templates/_helpers.tpl +++ b/charts/plane-enterprise/templates/_helpers.tpl @@ -420,6 +420,9 @@ more often than right. Set the floor to "" to bypass. {{- $rmq := .rabbitmq -}} {{- $floor := $rmq.minPlaneVersion | default "" -}} {{- if $floor -}} + {{- if not (regexMatch "^v?[0-9]+(\\.[0-9]+){0,2}$" $floor) -}} + {{- fail (printf "\n\nrabbitmq.minPlaneVersion must be a version like \"3.2.0\", or \"\" to disable\nthe check. Got %q, which cannot be compared and would break every render.\n" $floor) -}} + {{- end -}} {{- $tag := splitList ":" ($rmq.image | default "") | last -}} {{- $major := regexFind "^[0-9]+" $tag -}} {{- if and $major (ge (atoi $major) 4) -}} diff --git a/charts/plane-enterprise/values.yaml b/charts/plane-enterprise/values.yaml index cded75f..b712a7e 100644 --- a/charts/plane-enterprise/values.yaml +++ b/charts/plane-enterprise/values.yaml @@ -261,7 +261,11 @@ services: # rejects a negotiated frame_max below 8192; amqplib sent 4096 until 0.10.6, # so an older app silently loses its silo/live consumers when the broker # moves. Rendering fails with an explanation instead. Set to '' to bypass. - # MUST be set to the first Plane release carrying the fix before release. + # MUST be set at release time to the FIRST Plane release whose images carry + # the amqplib bump -- normally the same value as Chart.yaml appVersion for + # that release. It then stays pinned there; do not raise it in later chart + # releases, or you will block app versions that are actually fine. A leading + # 'v' is accepted. minPlaneVersion: '' servicePort: 5672 managementPort: 15672