Handoff: generating and applying the Forklift manifests

Handoff turns one approved wave into the Plan, NetworkMap and StorageMap your cluster already understands, then gives you the file.

Pick the plan and the wave. Manifests are emitted from a wave somebody planned and agreed to, never from the inventory directly. A machine that merely became ready afterwards was never reviewed for that night, and the first anybody would know is when it went down.

The current findings still get a veto. The plan is a snapshot; the inventory is now. If a machine picked up a blocker since the plan was saved — an RDM attached last week, a snapshot nobody deleted — it comes out of the manifest and is listed, with the reason, under "machines left out."

Name the objects that already exist in your cluster. The source and target Providers, the Forklift namespace, and the namespace the VMs land in. Turtini creates none of them: a Provider references a Secret you made yourself, and no credential passes through this module at all.

Type the mappings. Each vSphere port group to a NetworkAttachmentDefinition (or "pod" for the default pod network), and each datastore to the StorageClass that receives it. Nothing can infer these for you, and a wrong guess is the worst kind of wrong — it applies perfectly and puts every disk in the wrong place. The form refuses to generate until every row is filled in.

Then download the YAML and apply it yourself with kubectl.

Before you trust it with a window: apply it to a non-production namespace and read what the controller says. These manifests are written from the forklift.konveyor.io v1beta1 API and have not been validated against a live cluster. That is stated on the page too, for the same reason it is stated here.