feat(azure): run azure cells on FoundationDB, and give the install 2400s by IliaFeldgun · Pull Request #96 · pinecone-io/pulumi-pinecone-byoc

IliaFeldgun · 2026-08-19T17:15:38Z

The Flexible Server component and its config go the way aws's RDS did; db_net stays inside the vnet address space although nothing uses it, because dropping it from the supernet moves pls_net and that replaces the Private Link Service subnet under a live cell.

The install job gets 2400s. AKS node pools scale from zero, so a cold cell spends its first twenty minutes buying nodes and only then starts installing: two runs reached the data-plane check at T+27 and T+37 and were SIGKILLed mid index migration, with FoundationDB healthy underneath both times. aws keeps the 1800s default - its node groups are born at size 1, so it has never needed the room.

Note

High Risk
Removes a major data-plane dependency and changes secrets/outputs for Azure cells; VNet address planning is intentionally frozen to avoid replacing live Private Link subnets.

Overview
Azure BYOC stops provisioning PostgreSQL Flexible Server (module removed, config types dropped, cluster no longer wires Database or passes control_db / system_db into K8sSecrets). Stack exports for control/system DB endpoints are removed; deletion protection now protects the blob storage account and containers instead of the old database config.

Pinetools on Azure gets install_deadline_seconds=2400 (40 minutes) so cold AKS scale-from-zero installs can finish index migration without the job being killed at the default 1800s.

VNet drops the delegated PostgreSQL subnet but keeps the unused db_net slice in the supernet so the Private Link Service subnet address does not shift on existing stacks.

Setup wizard no longer checks PostgreSQL Flexible Server SKUs or requires Microsoft.DBforPostgreSQL.

^{Reviewed by Cursor Bugbot for commit 316d76f. Bugbot is set up for automated code reviews on this repo. Configure here.}

IliaFeldgun · 2026-08-20T10:48:25Z

2400 is probably fake news and looking to detect what's actually going on.

cursor

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4c3fded. Configure here.}

cursor · 2026-08-20T14:51:28Z

+        with:
+          name: e2e-azure-logs
+          path: .e2e-logs/
+          if-no-files-found: ignore


Azure CI logs stay hidden

Medium Severity

The new Azure upload step points at .e2e-logs/ but never sets include-hidden-files. upload-artifact@v4 skips dotted paths by default, and if-no-files-found: ignore hides that, so failed-run logs never land on the workflow. The AWS job already sets that flag for the same reason.

^{Reviewed by Cursor Bugbot for commit 4c3fded. Configure here.}

cursor · 2026-08-20T14:51:28Z


-      - name: Run wizard (non_interactive)
-        id: wizard
+      - name: Deploy a cell and snapshot it if it fails


Install deadline exceeds job timeout

Medium Severity

AZURE_INSTALL_DEADLINE_SECONDS is 2400, so the pinetools Job may run 40 minutes inside pulumi up, but the Azure up workflow is still timeout-minutes: 60. AKS provisioning plus that deadline routinely overruns the runner, which SIGKILLs the job the same way the 1800s cap did. AWS’s e2e up job allows 150 minutes for this reason.

Additional Locations (2)

pulumi_pinecone_byoc/azure/cluster.py#L38-L39

pulumi_pinecone_byoc/azure/cluster.py#L392-L393

^{Reviewed by Cursor Bugbot for commit 4c3fded. Configure here.}

The Flexible Server component and its config go the way aws's RDS did; db_net stays inside the vnet address space although nothing uses it, because dropping it from the supernet moves pls_net and that replaces the Private Link Service subnet under a live cell. The install job gets 2400s. AKS node pools scale from zero, so a cold cell spends its first twenty minutes buying nodes and only then starts installing: two runs reached the data-plane check at T+27 and T+37 and were SIGKILLed mid index migration, with FoundationDB healthy underneath both times. aws keeps the 1800s default - its node groups are born at size 1, so it has never needed the room. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Azure deployed by hand: a wizard step, a stack select, three config sets, a pulumi up, and a teardown that repeated all of it. Nothing watched the cluster, so when the install failed the reason went with the teardown - twice this week a pod's own output was the only place the answer lived and nobody had it. It runs through the same fixture aws does now. deployed_project takes a cloud, the region and zones come from settings instead of the workflow's env block, and the two jobs are one pytest call each. The e2e log lands as an artifact. capture_failed_deploy stopped being an EKS call: a stack exports update_kubeconfig_command whatever cloud it is on, and a failed up still has it, so the postmortem asks the stack how to reach the cluster and works everywhere. Following the installer live still needs to find a cluster that does not exist yet, which is an EKS lookup, so that stays aws-only and the others get the snapshot at the end. The azure test asserts what the workflow asserted - the deploy exported an environment - because the cell is deployed with public access off and there is nothing to probe from a runner. An azure marker keeps it out of the aws leg. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The azure job installs --extra azure, and pytest imports every module under testpaths before -m deselects anything, so tests/vpc and tests/wizard/test_existing_vpc.py - which import pulumi_pinecone_byoc.aws - ended both azure legs in ModuleNotFoundError after thirty seconds, with nothing deployed. aws never saw it because --extra aws has pulumi_aws. conftest reads each file's import statements and skips the ones that name a cloud SDK this environment does not have. It also takes tests/vpc out of the azure destroy leg, which had been selecting an AWS VPC teardown by marker alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The postmortem described the first twenty not-ready pods in `kubectl get pods -A` order, which is namespace-alphabetical: a deploy that stalls on foundationdb leaves enough pending pods ahead of pc-control-plane to spend the whole limit before reaching the install job. It sorts the install namespace first now, so the pod that knows why is always among them. A pod the autoscaler drains is deleted through the eviction API, so nothing is left to describe and the reason lives only in events. It captures the install Job and the tail of the cluster's events, where OOMKilling, Evicted, ScaleDown and FailedScheduling all name themselves. Both go through logging, so the redaction filter sees them; the job describe is scoped to pc-control-plane, whose pod template carries a version and a timeout and reaches its credentials by reference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

IliaFeldgun · 2026-09-03T14:44:05Z

#103
The bug fix is here, no need for 2400s 👍
The pytest will be merged separately.

IliaFeldgun temporarily deployed to aws-e2e August 19, 2026 22:37 — with GitHub Actions Inactive

IliaFeldgun temporarily deployed to aws-e2e August 19, 2026 23:14 — with GitHub Actions Inactive

IliaFeldgun had a problem deploying to azure-e2e August 19, 2026 23:45 — with GitHub Actions Failure

IliaFeldgun temporarily deployed to azure-e2e August 20, 2026 00:20 — with GitHub Actions Inactive

IliaFeldgun force-pushed the ilia/azure-fdb branch from 316d76f to 4c3fded Compare August 20, 2026 14:48

cursor Bot reviewed Aug 20, 2026

View reviewed changes

IliaFeldgun temporarily deployed to aws-e2e August 20, 2026 18:02 — with GitHub Actions Inactive

IliaFeldgun temporarily deployed to aws-e2e August 20, 2026 18:41 — with GitHub Actions Inactive

IliaFeldgun had a problem deploying to azure-e2e August 20, 2026 19:11 — with GitHub Actions Failure

IliaFeldgun had a problem deploying to azure-e2e August 20, 2026 19:12 — with GitHub Actions Failure

IliaFeldgun and others added 3 commits August 25, 2026 21:43

IliaFeldgun force-pushed the ilia/azure-fdb branch from 5b7f573 to 2f09376 Compare August 25, 2026 21:45

IliaFeldgun temporarily deployed to aws-e2e August 25, 2026 22:37 — with GitHub Actions Inactive

IliaFeldgun temporarily deployed to aws-e2e August 25, 2026 23:18 — with GitHub Actions Inactive

IliaFeldgun temporarily deployed to azure-e2e August 25, 2026 23:47 — with GitHub Actions Inactive

IliaFeldgun temporarily deployed to azure-e2e August 26, 2026 00:38 — with GitHub Actions Inactive

IliaFeldgun marked this pull request as draft September 3, 2026 14:44

Navigation Menu

Uh oh!

feat(azure): run azure cells on FoundationDB, and give the install 2400s - #96

feat(azure): run azure cells on FoundationDB, and give the install 2400s#96
IliaFeldgun wants to merge 4 commits into
mainfrom
ilia/azure-fdb

IliaFeldgun commented Aug 19, 2026 •

edited by cursor Bot

Loading

Uh oh!

IliaFeldgun commented Aug 20, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

cursor Bot Aug 20, 2026

Uh oh!

cursor Bot Aug 20, 2026

Uh oh!

IliaFeldgun commented Sep 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

IliaFeldgun commented Aug 19, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IliaFeldgun commented Aug 20, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor Bot Aug 20, 2026

Choose a reason for hiding this comment

Azure CI logs stay hidden

Uh oh!

cursor Bot Aug 20, 2026

Choose a reason for hiding this comment

Install deadline exceeds job timeout

Uh oh!

IliaFeldgun commented Sep 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

IliaFeldgun commented Aug 19, 2026 •

edited by cursor Bot

Loading