Skip to content

Latest commit

 

History

History
65 lines (48 loc) · 3.36 KB

about-hooks-for-migration-plans.adoc

File metadata and controls

65 lines (48 loc) · 3.36 KB

About hooks for {project-short} migration plans

You can add hooks to {project-first} migration plans using either the {project-short} CLI or the {project-short} user interface, which is located in the {ocp} web console.

  • Pre-migration hooks are hooks that perform operations on a VM that is located on a provider. This prepares the VM for migration.

  • Post-migration hooks are hooks that perform operations on a VM that has migrated to {virt}.

Default hook image

The default hook image for an {project-short} hook is quay.io/konveyor/hook-runner. The image is based on the Ansible Runner image with the addition of python-openshift to provide Ansible Kubernetes resources and a recent oc binary.

Hook execution

An Ansible playbook that is provided as part of a migration hook is mounted into the hook container as a ConfigMap. The hook container is run as a job on the desired cluster in the openshift-mtv namespace using the ServiceAccount you choose.

When you add a hook, you must specify the namespace where the Hook CR is located, the name of the hook, and whether the hook is a pre-migration hook or a post-migration hook.

Important

In order for a hook to run on a VM, the VM must be started and available using SSH.

The illustration that follows shows the general process of using a migration hook. For specific procedures, see Adding a migration hook to a migration plan using the {ocp} web console and Adding a migration hook to a migration plan using the CLI.

Adding a hook to a migration plan
Figure 1. Adding a hook to a migration plan

Process:

  1. Input your Ansible hook and credentials.

    1. Input an Ansible hook image to the {project-short} controller using either the UI or the CLI.

      • In the UI, specify the ansible-runner and enter the playbook.yml that contains the hook.

      • In the CLI, input the hook image, which specifies the playbook that runs the hook.

    2. If you need additional data to run the playbook inside the pod, such as SSH data, create a Secret that contains credentials for the VM. The Secret is not mounted to the pod, but is called by the playbook.

      Note

      This Secret is not the same as the Secret CR that contains the credentials of your source provider.

  2. The {project-short} controller creates the ConfigMap, which contains:

    • workload.yml, which contains information about the VMs.

    • playbook.yml, the raw string playbook you want to execute.

    • plan.yml, which is the Plan CR.

      The ConfigMap contains the name of the VM and instructs the playbook what to do.

  3. The {project-short} controller creates a job that starts the user specified image.

    1. Mounts the ConfigMap to the container.

      The Ansible hook imports the Secret that the user previously entered.

  4. The job runs a pre-migration hook or a post-migration hook as follows:

    1. For a pre-migration hook, the job logs into the VMs on the source provider using SSH and runs the hook.

    2. For a post-migration hook, the job logs into the VMs on {virt} using SSH and runs the hook.