Plan and Apply

Before anything touches your infrastructure, CrossXCloud diffs your canvas against what actually exists and shows you every change it is about to make. This is the Plan and Apply loop. For the model behind it, see Reconciliation.

Open Plan

Open the Plan action from the menu bar. CrossXCloud reads your current infrastructure from the provider, compares it against the canvas, and produces an ordered list of operations.

A plan always runs against freshly read live state. It is never resumed from a previous run. If you change the canvas, Plan again.

Read the diff

The Plan screen shows a summary with badges:

• Green for create. A new resource will be added.
• Blue for update. An existing resource will have a field changed in place.
• Red for delete. An existing resource will be destroyed.
• Purple for attach or detach. A membership edge will be added or removed.

Each row is one operation. The operations are in dependency order: networks are created before servers, and servers are created before their memberships. Deletions run in reverse.

Immutable fields become replace

Some fields cannot be updated in place on the provider. When you change one of these on an existing node, CrossXCloud plans a delete and a create instead of a silent update. The plan labels this so you can see it is a replacement.

Apply

Apply runs every operation in the plan, in order, against your provider. Progress is shown live as it goes.

There is no per-step confirmation. You review the whole plan once and then Execute, and the engine runs every operation sequentially. This is auto-apply. If you want to recheck before applying, just do not press Execute.

When an operation fails

If an operation fails, the remaining operations are cancelled. The canvas is unchanged. Your provider state may be partially applied.

To recover, fix the cause, open Plan again, and Apply again. The new plan is computed against the now partially applied live state, so it picks up exactly where things left off without redoing what already succeeded.

There is no resume-from-failed-op. Every plan is fresh.

Every Apply is recorded

When an Apply finishes, whether fully applied, partially applied, or failed, CrossXCloud writes a commit to the project history. The commit captures the desired state, the plan, and the per-operation results. See Version history.

Next

• Reconciliation for the model behind the diff and the ordering.
• Version history for browsing and rolling back.
• The canvas for how edits become the desired state.