|
| 1 | +# Migrate Internal v0 Configurations To v1 |
| 2 | + |
| 3 | +The first public Kernel provider release is v1. Earlier v0 builds and tags were |
| 4 | +internal release candidates, so there is no public registry upgrade path or |
| 5 | +published v0 state migration. |
| 6 | + |
| 7 | +## Existing Browser Pools |
| 8 | + |
| 9 | +The provider source address remains `kernel/kernel`, and existing |
| 10 | +`kernel_browser_pool` state remains the same resource type. Before upgrading: |
| 11 | + |
| 12 | +1. Run `terraform plan` with the current internal provider build and save the output. |
| 13 | +2. Upgrade to v1 in a non-production workspace first. |
| 14 | +3. Run `terraform plan` again and review every durable field, especially project scope, profile/proxy references, ordered extensions, Chrome policy, viewport, launch settings, and warmup settings. |
| 15 | +4. Do not accept a plan that introduces runtime counters, lease state, standby state, or browser-session operations; v1 does not model them. |
| 16 | + |
| 17 | +Browser-pool deletion remains non-forceful. V1 does not terminate leased |
| 18 | +browsers to make deletion succeed. |
| 19 | + |
| 20 | +## Adopt Existing Resources |
| 21 | + |
| 22 | +Add valid destination resource blocks before importing. The names and pool size |
| 23 | +below are illustrative; reconcile every configured field with the remote object |
| 24 | +before applying: |
| 25 | + |
| 26 | +```hcl |
| 27 | +resource "kernel_project" "example" { |
| 28 | + name = "existing-project-name" |
| 29 | +} |
| 30 | +
|
| 31 | +resource "kernel_browser_pool" "example" { |
| 32 | + name = "existing-pool-name" |
| 33 | + size = 1 |
| 34 | +} |
| 35 | +
|
| 36 | +resource "kernel_extension" "example" {} |
| 37 | +``` |
| 38 | + |
| 39 | +Then import each durable object. Choose only one import form for each |
| 40 | +project-scoped resource: |
| 41 | + |
| 42 | +```sh |
| 43 | +terraform import kernel_project.example <project-id> |
| 44 | + |
| 45 | +# Browser pool: choose the bare or project-qualified form. |
| 46 | +terraform import kernel_browser_pool.example <browser-pool-id> |
| 47 | +# or |
| 48 | +terraform import kernel_browser_pool.example <project-id>/<browser-pool-id> |
| 49 | + |
| 50 | +# Extension: choose the bare or project-qualified form. |
| 51 | +terraform import kernel_extension.example <extension-id> |
| 52 | +# or |
| 53 | +terraform import kernel_extension.example <project-id>/<extension-id> |
| 54 | +``` |
| 55 | + |
| 56 | +Use project-qualified import when the object is outside the resolved project |
| 57 | +scope: the provider default when configured, otherwise the API key's project |
| 58 | +binding. After import, run `terraform plan` and reconcile configuration with |
| 59 | +the durable state returned by Kernel before applying changes. |
| 60 | + |
| 61 | +Extension import is metadata-only: it cannot recover the original local archive |
| 62 | +path. Managing future content replacement requires Terraform 1.11 or later plus |
| 63 | +`source_path` and `source_sha256 = filesha256(source_path)`. |
| 64 | + |
| 65 | +## Newly Available Lookups |
| 66 | + |
| 67 | +V1 adds lookup-only app and browser-pool data sources alongside project, |
| 68 | +profile, proxy, and extension lookups. Data sources do not adopt or mutate the |
| 69 | +remote object. Exact lookup fails when no object or multiple objects match. |
| 70 | + |
| 71 | +## Deferred Surfaces |
| 72 | + |
| 73 | +Do not translate SDK or API operations into ad hoc Terraform resources while |
| 74 | +waiting for deferred v1.x work. API key, profile, proxy, and deployment |
| 75 | +resources remain unavailable until their documented durable and sensitive-state |
| 76 | +contracts are complete. App invocation, browser sessions, logs, screenshots, |
| 77 | +live view, health checks, and recovery operations remain outside Terraform. |
0 commit comments