Repository navigation
feat: configure persistent volume capacity per deployment - #1000
Conversation
|
Enclave skipped this draft pull request. It will run automatically when you mark the PR as Ready for review. |
|
@greptileai please review the volume sizing implementation, growth-only validation, provider bounds, setup parameter handling, and compatibility. |
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
@greptileai review: restored compatibility exports through the existing generator, validate resolved release defaults against provider limits, preserve existing storage quantities, and allow Kubernetes mount-only changes. API documentation will be regenerated from the corrected source contract. |
|
@greptileai Unchanged Kubernetes quantity spellings now bypass parsing entirely, preserving every quantity accepted at installation, including decimal exponents. Equivalent supported quantities retain the installed PVC spelling. Please re-review the update guard. |
|
@greptileai Added the documented Azure Standard_D2s_v4 catalog entry after the live SKU API confirmed that available machine was rejected during setup selection. Please re-review the catalog addition. |
…key (#1019) ALIEN-1477. alien-core tests don't compile on main (`d07764433`): #1000 added compute planner tests that build `PersistentStorage` without the `encryption_key` field #1005 added. The two PRs merged one after the other, so each passed CI alone. `cargo test -p alien-core` fails with E0063 at `compute_planner.rs` 1312, 1462 and 1518. Main's Tests workflow is skipped on push, so it only shows on PRs whose test selection includes alien-core. This sets `encryption_key: None` in the three fixtures. Test-only, no behavior change. Checked in a Linux sandbox on main (via #1012, which merges main) + this commit: `cargo check --workspace --all-targets` is clean, `cargo nextest run -p alien-core` 660/660 pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
1 participant
Adds
compute.containers.<id>.volumeSizeGibso deployments can select initial persistent capacity per replica and retain it across releases. Existing volumes may grow; planning rejects shrink, storage removal and mount-path changes and validates provider bounds. Kubernetes supports initial sizing and explicitly rejects runtime resizing pending CSI/StatefulSet support.CloudFormation exposes a numeric volume parameter, including for persistent containers without CPU/memory choices. GCP and Azure clients resize existing disks. Azure node execution grants the dedicated VMSS disk-attachment action and the existing gateway subnet/public-IP read and join actions, all within the deployment resource group. These are control-plane permissions; no disk-content reads are added.
Validation: current CI is green, including Rust, TypeScript and worker integration. Focused core, CloudFormation and permission checks passed. Real AWS Terraform, AWS CloudFormation, GCP and Azure runs exercised initial 22→25 GiB growth, mounted capacity, durable records, process continuity, no-op and shrink rejection. The fresh Azure run recorded 157 successful writes, maximum 1289 ms, and authenticated 22 GiB filesystem allocation beyond the original capacity. No HTTP error was observed in that interval. Earlier GCP runs observed 502s during growth and before mutation; later passes do not establish unconditional availability. Azure validation used a real node identity with generated grants; it does not establish management OIDC behavior. Final Azure cleanup passed: 52 Terraform resources destroyed, with independent checks finding no owned role assignments, groups, resources or custom roles.
ALIEN-1441.