First thing you'll need to start hacking on MTC is a couple of clusters. The main use-case and the original impetus for the project is to migrate users from OCP 3.x -> 4.x because it was determined there would not be an in-place upgrade path. However, there is nothing that precludes MTC from alternative topologies and use-cases, such as 3.x -> 3.x, or 4.x -> 4.x. Most devs run a 3.11 and a 4.x cluster, where x is the latest stable ocp4 minor release.
There is a redhat project called agnosticd that a collection of ansible that helps users launch OCP clusters, and workloads to run on those clusters. We've wrapped agnosticd for our own specialized usage with mig-agnosticd. This is what most devs use to launch their 3.x and 4.x, although that is not required and any OCP cluster will do.
Once you have your basic clusters set up, you can install and set up the latest production release of MTC on your clusters following the downstream documentation on both of your clusters (ensure you follow the correct procedure for the correct cluster version).
It's very common during the course of development and testing to test custom
components within a broader production deployment (for example, running a
UI built from a PR with a controller built from a PR that the UI depends on).
This can be accomplished by setting specific arguments on the MigrationController.spec.
The operator will pick up these arguments and apply them to the appropriate
Deployment, re-deploying the specified image.
The UI team typically develops on the UI by running the webpack development server and serving off of the development workstation (or laptop). Instructions for configuring your setup for UI development can be found here.
Navigating to the root of the UI project, an image can be built from the code as present by simply building the Dockerfile, for example:
docker build -t quay.io/eriknelson/konveyor-ui:test $PROJECT_ROOT
Push this image to a registry (NOTE: if pushing to quay for the first time, your image must be marked public to be pullable from a cluster, otherwise you will get an image pull error while deploying).
Finally, edit the MigrationController CR that has deployed your MTC install
oc edit migrationcontroller -n openshift-migration migration-controller
Set the following vars on the spec, example:
mig_ui_image: quay.io/eriknelson/konveyor-ui
mig_ui_version: test
The controller project has a specific hacking guide that describes building and running a controller locally, and connecting to an existing MTC deployment for regular development.
Similar to the UI project, the controller's Dockerfile can be built and pushed with the sample process:
docker build -t quay.io/eriknelson/konveyor-controller:test $PROJECT_ROOT
To deploy the image, set the following variables on the MigrationController:
mig_controller_image: quay.io/eriknelson/konveyor-controller
mig_controller_version: test
MTC's fork of Velero lives here. This fork carries changes we need to adopt faster than it will be accepted upstream, but under nearly all cases, we seek to submit changes upstream and adopt them by rebases on top of the upstream version that contains it. The fork images can be built in the same way that is described in the project.
Setting the following variables on the MigrationController will override the velero image:
velero_image: quay.io/eriknelson/konveyor-velero
velero_version: test
The operator is responsible for the lifecycle of all the MTC components that make up a complete deployment. It is an example of an Ansible Operator, making it very flexible for change.
Unlike the operands that the operator manages, a custom operator is deployed in a different way depending on the version of the cluster.
In depth instructions for testing operator changes can be found in the operator HACKING.md.