Merge pull request #14 from Phala-Network/release/v0.3.0-beta.2

chore(release): cut 0.3.0-beta.2

Author: h4x3rotab

CHANGELOG.md

@@ -4,6 +4,27 @@ All notable changes to `terraform-provider-phala` are documented in this file.
 
 ## [Unreleased]
 
+## [0.3.0-beta.2] - 2026-05-19
+
+In-place updates work in members (MIG) mode for all the fields users actually edit. The release-blocking guardrail from 0.3.0-beta.1 is gone.
+
+### Added
+
+- `phala_app.Update` now propagates changes across every CVM in a members-mode app, preserving slot identity (`vm_uuid` and `name` are unchanged across the update):
+  - **Compose-body changes** (`docker_compose`, `pre_launch_script`, `public_logs`, `public_sysinfo`, `public_tcbinfo`, `gateway_enabled`, `secure_time`, env-key list) flow through the cloud's app-revision endpoint: provision + apply on the bootstrap CVM (which creates the revision row), then `POST /apps/{id}/revisions/{rev}/redeploy` with `vm_uuids = [other slots]`. Verified end-to-end on a 2-slot MIG: bootstrap update + slot redeploy lands the new `compose_hash` on every CVM with both `vm_uuid`s preserved.
+  - **Env value changes** (the common "rotate a secret" case) use a per-CVM `PATCH /cvms/{uuid}/envs` fan-out across every slot. The app-rooted KMS public key is shared across all CVMs in one app, so the same encrypted_env bytes are accepted by every slot. `compose_hash` stays unchanged (no new revision).
+  - **OS image changes** (`image`) fan out per-CVM via `PATCH /cvms/{uuid}/os-image` — the cloud has no app-level analog. Sequential, fail-fast.
+  - **Size / disk_size changes** fan out per-CVM via `PATCH /cvms/{uuid}/resources`. Same pattern.
+
+### Changed
+
+- `ModifyPlan` no longer blocks app-level mutable-field updates in members mode. The only structural check kept is the "cannot leave members mode in-place" guard, which still requires destroy + recreate when a user removes the `members` attribute from a previously-members-mode app.
+- Single-CVM apps (no `members`) follow the same single-CVM update path as before — PATCHes target the bootstrap directly with no fan-out machinery. Zero behavior change for that case.
+
+### Fixed
+
+- The members-mode guardrail's diagnostic message previously suggested workarounds (destroy+recreate, per-slot env) that are no longer needed for `docker_compose` / `env` / `image` / `size` / `disk_size`. Those workarounds were obsolete the moment we wired up the revision and fan-out paths; the message is gone with the guardrail.
+
 ## [0.3.0-beta.1] - 2026-05-18
 
 First prerelease of the 0.3 line. The provider's model collapses to:

FEATURE_MATURITY.md

@@ -1,6 +1,6 @@
 # Terraform Provider Feature Maturity
 
-Last updated: 2026-05-18
+Last updated: 2026-05-19
 
 ## Maturity Levels
 

docs/resources/app.md

@@ -56,17 +56,15 @@ When `members` is set, the provider enforces at plan time that `name` is one of
 
 Downstream `phala_app_instance` resources should set `for_each = toset(phala_app.foo.members)` so the slot list stays a single source of truth.
 
-## In-place updates are blocked in members mode
+## In-place updates in members mode
 
-The cloud's per-CVM PATCH endpoints (`/cvms/{id}/docker-compose`, `/envs`, `/os-image`, `/resources`, `/compose_file/provision`) only target a single CVM. Applying them through `phala_app` in members mode would mutate the bootstrap slot and leave every `phala_app_instance` slot on the old revision — divergent compose/env/image across the replica set. Until the cloud exposes an app-revision-aware update endpoint that preserves all named slots, this provider refuses at plan time to update any of these `phala_app` fields when `members` is set:
+`phala_app.Update` propagates mutable-field changes across every CVM in a members-mode app while preserving slot identity (`vm_uuid` and `name` are unchanged):
 
-`docker_compose`, `pre_launch_script`, `env`, `encrypted_env`, `env_keys`, `env_compose_hash`, `env_transaction_hash`, `image`, `size`, `disk_size`, `public_logs`, `public_sysinfo`, `public_tcbinfo`, `gateway_enabled`, `secure_time`.
+- **Compose-body changes** (`docker_compose`, `pre_launch_script`, `public_*`, `gateway_enabled`, `secure_time`, env-key list changes) go through the cloud's app-revision endpoint. The provider provisions + applies on the bootstrap CVM (creating a new revision row), then `POST /apps/{id}/revisions/{rev}/redeploy` fans the same revision out to every other slot. Each CVM's `compose_hash` flips to the new value; nothing is destroyed and recreated.
+- **Env value changes** (the common "rotate a secret" case) use a per-CVM `PATCH /cvms/{uuid}/envs` fan-out. The app-rooted KMS public key is shared across all slots, so the same encrypted_env bytes are accepted by every slot. `compose_hash` stays unchanged (no new revision).
+- **OS image, instance size, and disk size changes** fan out via `PATCH /cvms/{uuid}/os-image` and `PATCH /cvms/{uuid}/resources` respectively — the cloud has no app-level analog. Sequential, fail-fast.
 
-Workarounds:
-1. Destroy the `phala_app` + matching `phala_app_instance` resources and recreate them with the new compose / env / image.
-2. Move per-slot variations to `phala_app_instance.env` (per-slot encrypted env at create time; immutable thereafter).
-
-Adding or removing entries from `members` is still safe (it just spawns or destroys `phala_app_instance` resources). Removing the `members` attribute entirely is **not** safe and is also blocked at plan time — destroy and recreate the app.
+The one structural change still blocked is **removing the `members` attribute** from a previously-members-mode app: that would leave the `phala_app_instance` slots orphaned. The provider blocks this at plan time and asks you to destroy and recreate.
 
 ## Migration from 0.2.x
 

internal/provider/cvm_helpers.go

@@ -46,6 +46,13 @@ type cvmAPIResponse struct {
 	InstanceType string `json:"instance_type"`
 	DiskSize     *int64 `json:"disk_size"`
 
+	// ComposeHash is the SHA-256 of the canonical app compose body the
+	// cloud believes this CVM is currently running. After the redeploy
+	// fan-out, each CVM's `compose_hash` flips from the old revision's
+	// value to the new one — used by waitForCVMsOnComposeHash to detect
+	// completion of the async update.
+	ComposeHash string `json:"compose_hash"`
+
 	Progress *struct {
 		Target string `json:"target"`
 	} `json:"progress"`