Preflight passes but deployment fails on quota and Key Vault name length, after billable resources are created

[appliedi]

Summary

Three related gaps in kars up: the default node footprint exceeds a default Azure subscription's quota, baseName length is not validated against the Key Vault naming limit, and neither is caught by preflight — so both failures happen only after billable resources exist, with no rollback.

Version

@kars-runtime/cli@0.1.26

1. Default footprint exceeds a default subscription's quota

ErrCode_InsufficientVCPUQuota: requested 16, remaining 10 for family
standardDSv3Family for region westus3

The template requests 16 vCPU:

Pool	Count	Source	vCPU
system	2	hardcoded in modules/aks.bicep	4 (at D2s_v3)
clawpool	nodeCount, default 3	main.bicep	12 (at D4s_v3)

A default Azure pay-as-you-go subscription carries 10 vCPU per family. nodeCount is a Bicep parameter but is not exposed as a kars up flag, and the system pool count is hardcoded — so the footprint cannot be reduced through any supported interface.

This means the documented "one command to go from zero to production" cannot succeed on a default subscription without a prior quota increase.

2. baseName length is not validated

VaultNameNotValid: The vault name '<baseName>-kv-<6-char-suffix>' is invalid.
A vault's name must be between 3-24 alphanumeric characters.

main.bicep builds the vault name as '${baseName}-kv-${kvSuffix}' with a 6-character suffix, so baseName must be 14 characters or fewer. A 15-character --cluster-name fails. The constraint is not documented in kars up --help and is not checked by preflight.

3. Failures leave billable resources behind

Both failures occur after ACR, Key Vault, Log Analytics, Application Insights and an Azure OpenAI account have been created. There is no rollback. The Azure OpenAI account additionally soft-deletes and needs an explicit az cognitiveservices account purge before the name and quota are freed.

Suggested fixes

• Validate baseName length in preflight against the Key Vault 24-character limit (cheap, deterministic).
• Check available vCPU quota for the chosen family and region in preflight, comparing against the computed footprint, and fail before creating anything.
• Expose --node-count and a system-pool count, or lower the defaults so a default subscription can complete a first deploy.
• Consider deploying AKS before the supporting resources, or offering a --rollback-on-failure option, so a failed run does not leave a billable OpenAI account behind.

[appliedi]

Follow-up with a measured figure, since "the default is too big" is more useful with a number attached.

I tried reducing the footprint to fit a default 10 vCPU/family quota and went too far — dropping the system pool from 2 nodes to 1. That fails, and the reason is worth recording: a single Standard_D2s_v3 system node runs 27 system pods requesting 1812m of 1900m allocatable CPU (95%) once Cilium, the CSI drivers, ContainerInsights and coredns are present. The kars controller could not schedule:

0/2 nodes are available: 1 Insufficient cpu, 1 node(s) had untolerated taint(s).

Not the controller's fault — its requests are modest (100m CPU / 128Mi, no node selector, no anti-affinity). And the sandbox pool can't absorb it, correctly, because of the kars.azure.com/sandbox=true:NoSchedule taint.

So the system pool default of 2 is justified and shouldn't be lowered. The reducible part is the sandbox pool. Measured minimum for a single-sandbox evaluation:

Pool	Nodes	Size	vCPU
system	2 (default, required)	Standard_D2s_v3	4
clawpool	1 (default is 3)	Standard_D4s_v3	4
Total			8

8 vCPU fits inside a default subscription's 10; the stock 16 does not. That makes the narrow fix just exposing nodeCount as a kars up flag — the existing Bicep parameter is already there, it simply isn't reachable from the CLI. A preflight quota check comparing available vCPU against the computed footprint would turn the remaining failure into an actionable message instead of a mid-deploy error.

Happy to test a patch if useful.

[pallakatos]

Thanks Jess (@appliedi) for both the original report and the measured follow-up. The system-pool data is especially useful: we agree the two-node system pool is justified and should not be reduced. We are treating #515–#518 as one kars up deployment-safety workstream. For this issue the planned fix is early derived-name validation, an exposed sandbox --node-count, quota-family accounting against the complete requested footprint, safe adaptation from three sandbox nodes to one when appropriate, and bounded cleanup that can never delete a pre-existing resource group. We will post concrete validation results here, and your offer to retest the patch is appreciated.

[pallakatos]

Jess (@appliedi), the quota/name/rollback hardening is now available in draft #531 and its full CI/security matrix is green. Your measured two-system-node plus one-sandbox-node footprint directly informed the implementation.

Using the branch instructions on #531 and a disposable non-production subscription, the most valuable checks are:

1. Run the fresh West US 3 deployment from fix(cli): harden Azure deployment safety #531 without --node-count; preflight should print the full family/total-vCPU calculation and adapt the sandbox pool from three nodes to one when that is the largest safe footprint.
2. Repeat with --node-count 1 to confirm the explicit 8-vCPU topology.
3. Try an overlong --cluster-name; it should fail during preflight before billable resources are created.
4. If a later deployment step fails with --rollback-on-failure, confirm the generated resource group and Kars-owned locks are removed and the derived soft-deleted Key Vault name is purged/recoverable as reported.

Please post selected SKUs/counts, quota calculations, cleanup outcome, and any unexpected behavior on #531. Redact subscription, tenant, and generated-resource identifiers. Thank you again for offering to validate this against a real customer-shaped subscription.

[pallakatos]

The draft fix is now available in #531 and the complete CI matrix is green. It keeps the two-node system pool, exposes/validates the sandbox node count, checks total and VM-family quota plus generated-name limits before billable deployment, and adds bounded generated-resource-group rollback with purge-protected Key Vault recovery.

Jess (@appliedi), your offered retest would be particularly helpful here. A useful case is West US 3 with --node-count 1 in a subscription with the standard 10-vCPU family quota. Please share results on #531, including any preflight message or Azure failure. The PR remains draft pending this deployment feedback.