Skip to main content

Moving components modules into core

In order to migrate a terraform module from components into core, there are a number of steps that need to be taken in order to make sure the process runs smoothly. From a high level, the terraform module needs to be moved and then tested in a test cluster.

The aim is to make sure that when a terraform plan is run against both core and compoents after the MTM tool is ran, there should be no terraform changes.

There is a pipeline in Concourse that accepts $CLUSTER_NAME, $MODULE_NAME and $RESOURCE setting these and running the pipeline will migrate that module/resource on the cluster specified. Resources can be passed as comma-seperated strings. Getting a list of resources to migrate is a manual process that requires you to read through the terraform files in components. Some can be found by tracing back dependencies, others should be obvious via there name. The name format for resources follow $resource_type.$resource name so resource "kubernetes_storage_class" "storageclass" becomes kubernetes_storage_class.storageclass, you can double check this by running terraform state list.

If you need to upgrade the mtm cli, you can update the $MTM_VERSION parameter in the pipeline.

Notes on the pipeline

The pipeline takes the following arguments:

  • cluster_name - Name of the cluster to target e.g. cp-0001-0001.
  • module_name - Name of the module to target e.g. cert_manager.
  • resource - Name of the resource to target e.g. kubectl_manifest.prometheus_operator_crds, accepts a comma-separated list for multiple resources.
  • flagged_resource Name of flagged resource to target, this is used for resources that need to be pulled out of a module, accepts a comma-separated list for multiple resources.

Because of the way concourse variables work, none of the above can be blank. You can pass a dummy string in like module.null and the MTM tool will try to migrate a module/resource that doesn’t exist.

 Process

  1. Notify #cloud-platform that you are pausing concourse pipelines
  2. Pause bootstrap, live-2, manager and live pipelines.
  3. Raise a PR with migrated module
  4. Log in to Concourse using fly -t moj-cp login -c https://concourse.cloud-platform.service.justice.gov.uk/
  5. Ensure you are in the cloud-platform-terraform-concourse directory.
  6. Update pipelines with module and/or resource(s) name(s) and cluster name: fly -t moj-cp set-pipeline --pipeline migrate-module --config migrate-module.yaml -v cluster_name=cp-0306-0730 -v module=tigera_calico -v resources=kubectl_manifest.calico_crds,http.calico_crds -v flagged_resources=module.null
  7. Run migrate-module pipeline from the Concourse UI.
  8. Unpause pipeline environment-specific pipeline (e.g. live-2)
  9. Re-run PR plan - the plan should show “No changes. Your infrastructure matches the configuration.”
  10. Re-run step 5-9 with the next environment (e.g. manager)
  11. Get approval for the PR and merge.
  12. Un-pause live-2 and check for a clean apply
  13. Repeat 9. with manager and live
  14. Update #cloud-platform informing the team of the completed migration and that pipelines are unpaused.

Disaster Recovery

If for some reason something goes wrong, then you can use the backed up state file to overwrite the remote.

Alternatively, all our tf state objects are versioned in S3 so you can restore a previous known working version from the AWS console.

This page was last reviewed on 12 August 2025. It needs to be reviewed again on 12 February 2026 by the page owner #cloud-platform .
This page was set to be reviewed before 12 February 2026 by the page owner #cloud-platform. This might mean the content is out of date.