Breaking changes and removals

Astro Private Cloud (APC) 2.0 restructures, renames, and removes several Helm values. This page outlines each change, its user impact, and migration steps.

​

Feature flag restructuring (boolean → nested)

​

Background

In APC 2.0, scattered global.* boolean flags are reorganized into domain-grouped structures with a consistent .enabled pattern. This improves consistency and makes the configuration schema easier to extend.

​

Affected keys

​

Subtree moves

​

Impact

• APC 2.0 silently ignores any values.yaml overrides that use the old key paths, causing values to fall back to chart defaults.

​

Required action

Run the appropriate migration script before upgrading:

• From 1.x: bin/migrate-helm-chart-values-1x-to-2x.py
• From 0.37.x: bin/migrate-helm-chart-values-037x-to-2x.py

​

APC API config deployment flag restructuring

​

Background

In addition to the global.* feature flags, the APC API configuration flags under astronomer.houston.config.deployments have also been restructured into domain-grouped nested paths. The migration scripts handle these automatically.

​

Restructured keys (boolean → nested)

All paths above are relative to astronomer.houston.config.deployments.

​

Relocated keys

​

Deleted keys

​

Impact

• APC 2.0 silently ignores any values.yaml overrides that use the old key paths under astronomer.houston.config.deployments, causing values to fall back to APC API defaults.

​

Required action

Run the appropriate migration script before upgrading. The scripts handle both global.* and astronomer.houston.config.deployments.* key restructuring.

​

Fluentd replaced by Vector (0.37.x → 2.0 only)

​

Background

APC 2.0 uses Vector for log collection instead of Fluentd. The migration script renames the top-level fluentd key to vector, preserving resource requests and limits.

​

Impact

• Resource values (CPU, memory) carry over automatically.
• Custom Fluentd configuration — such as custom pipelines, filters, output plugins, or parser definitions — doesn’t translate to Vector format.

​

Required action

If you have custom Fluentd configuration:

​

Kibana removed (0.37.x → 2.0 only)

​

Background

APC 2.0 no longer includes Kibana. The migration script deletes the top-level kibana section.

​

Impact

• The kibana.<BASEDOMAIN> endpoint is no longer available after upgrade.
• Elasticsearch remains available for log storage and can be queried directly or via external tools.

​

Required action

If you rely on Kibana for log viewing, set up an alternative log viewing solution (such as Grafana with Loki, or direct Elasticsearch queries) before upgrading.

​

Prometheus blackbox exporter removed (0.37.x → 2.0 only)

​

Background

APC 2.0 no longer includes the Prometheus blackbox exporter. The migration script deletes the top-level prometheus-blackbox-exporter section.

​

Impact

If you rely on blackbox probing for uptime monitoring of platform services, that monitoring will stop after the upgrade.

​

Required action

Set up alternative uptime monitoring before upgrading if you depend on blackbox exporter probes.

​

PgBouncer port changed: 5432 → 6543 (0.37.x → 2.0 only)

​

Background

The default PgBouncer service port changes from 5432 to 6543 to avoid conflict with the PostgreSQL default port.

​

Impact

External services or scripts connecting to PgBouncer on port 5432 will fail to connect after the upgrade.

​

Required action

Update any external services, connection strings, or scripts that reference the PgBouncer port. If you need to keep port 5432, set global.pgbouncer.servicePort: "5432" in your override file after migration.

​

PgBouncer secret key renamed (0.37.x → 2.0 only)

​

Background

The PgBouncer configuration key global.pgbouncer.krb5ConfSecretName is renamed to global.pgbouncer.secretName. The migration script handles this automatically.

​

Impact

The underlying Kubernetes Secret is unchanged — only the Helm values key name changes.

​

Required action

Verify that the value carried over correctly after migration.

​

PgBouncer client authentication and its CPU cost carry over

​

Background

The Airflow Helm chart sets the PgBouncer auth_type to scram-sha-256 — the upstream default since Airflow chart 1.12.0, first bundled in Astronomer Software 0.37.4. Helm remains the default deployment mode on APC 2.x, and an existing Deployment can’t be converted from Helm mode to operator mode. Every Deployment that survives an upgrade therefore stays Helm-rendered, and the auth_type and extraIni overrides under astronomer.houston.config.deployments.helm.airflow.pgbouncer both remain fully effective.

​

Impact

With scram-sha-256 and a plain-text password in the PgBouncer auth file, PgBouncer derives a SCRAM secret using PBKDF2 with 4096 iterations on every client login, and PgBouncer is single-threaded. The default PgBouncer CPU request for a Deployment is 200m. Deployments with high connection churn — large DAG fan-outs, or many task Pods starting at the same scheduled time — can saturate the PgBouncer CPU. Because both the liveness and readiness probes are tcpSocket checks, saturation surfaces with no diagnostic output in the PgBouncer logs. The symptoms are:

• PgBouncer probe failures and container restarts, concentrated around peak scheduled runs.
• Idle server connections accumulating on the metadata database after each restart.
• Task failures across the Deployment while PgBouncer is unavailable.

Upgrading a Deployment re-renders and restarts its PgBouncer, which is when this typically surfaces.

​

Required action

1. Upgrade Deployments outside their scheduled batch windows, then watch PgBouncer CPU usage and container restarts through the first peak run.
2. Size PgBouncer for the login rate at peak rather than the average. See Customize resource usage.
3. To remove the per-login PBKDF2 cost entirely, set auth_type to md5:
   astronomer:
     houston:
       config:
         deployments:
           helm:
             airflow:
               pgbouncer:
                 auth_type: md5
   
   md5 is a weaker password authentication method than scram-sha-256. In this architecture the credential is already stored in plain text in a Kubernetes Secret mounted on both sides of the connection, and the connection is restricted to the Deployment namespace, so the practical difference is small — but confirm the choice against your own security requirements.

​

Exception: operator-mode Deployments

Deployments created in operator mode (APC 2.1 and later, opt-in, new Deployments only) don’t use these values. The Airflow custom resource has no auth_type field, and the operator authenticates clients with md5. Other PgBouncer settings, such as CPU and memory, still come from deployments.helm.airflow.pgbouncer and are covered under Feature support’s “Custom resource configuration (CPU and memory)” entry.

​

NATS JetStream enabled by default (0.37.x → 2.0 only)

​

Background

In 0.37.x, global.nats.jetStream.enabled defaults to false. In 2.x, it defaults to true.

​

Impact

JetStream requires persistent storage. Ensure your cluster has a storage class available for JetStream volumes.

​

Required action

Verify that your cluster supports persistent volumes for NATS JetStream. If you need to keep JetStream disabled, set global.nats.jetStream.enabled: false in your override file after migration.

​

Deleted keys (0.37.x → 2.0 only)

APC 2.0 removes the following keys. If you are upgrading from 1.x, 1.0 already removed them.

​

New keys added with defaults

The migration script adds the following keys with default values if they aren’t already present. Review each key and override the default if it doesn’t match your environment.