Blueprint imports, renames, and detached ownership

Blueprint imports, renames, and detached ownership

Adopt existing resources without creating duplicates or silently transferring ownership.

Blueprint imports associate an existing resource ID with a logical name in a managed definition. Import records ownership; it does not recreate the resource or make its current configuration match the definition automatically.

Preview an adoption

Add the desired resource entry to the definition and run an import preview with the logical name and existing ID. The resource must belong to the selected project and be a supported blueprint type.

From the directory containing the definition, preview adoption of drp_web01 as the logical entry web:

Shell
infra blueprints import --file payments.yaml \
  --resource web --id drp_web01 --preview

The preview compares actual configuration, requested values, current revision, and any existing management owner. A resource managed by another blueprint returns resource_already_managed. Ordinary project write permission does not authorize taking ownership from a different deployment record.

Apply the import

Apply the reviewed import plan with the plan-apply operation to record the mapping. The next normal plan can propose configuration changes for drift; import itself does not issue those changes as hidden side effects.

A stale revision blocks adoption until the preview is refreshed. A resource removed after preview cannot be substituted by another resource with the same display name. Import uses the immutable ID.

Rename a logical entry

Create a blueprint plan with mode rename when the managed resource must keep its identity. A rename changes the mapping and references within that blueprint revision. It does not rename the server resource unless its configured display name also changes.

Deleting web and adding frontend without a mapping rename proposes removal and creation according to ordinary planning rules. Deletion protection and retention still apply to the previous resource.

Concurrent plans

A blueprint holds a management lock while an apply mutates its mapped set. Another apply for the same blueprint returns blueprint_locked with the active operation. A saved plan also pins the blueprint's state revision.

An operator must not force-clear the lock because a CLI process exited. Inspect whether server work continues or is reconciling. Use operation recovery before releasing an unresolved owner.

Detach without deleting

Create a blueprint plan with mode detach to remove a resource from blueprint management while retaining the infrastructure. The review lists references that must be updated or converted to external IDs. Removing an entry from YAML normally proposes deletion instead; those are different actions.

Detached resources continue consuming quota and usage. Their original audit history remains. To adopt them elsewhere, create a new reviewed import after the prior ownership is released.

Use Blueprint API for plan, import, and state revision fields and resource transfer when the project owner itself changes.