Filesystem storage back ends

Migrations from source MSR 2.9.x systems that use Docker volumes for image storage can only be performed using the copy storage mode. Such migrations must have the Docker volume and associated Persistent Volume Claims (PVCs) mounted to the MMT container.

Important

To run the estimate and extract commands on a filesystem back end, you must download and configure the MKE client bundle.

  1. Obtain the name of the source MSR 2.9.x volume:

    docker volume ls --filter name=dtr-registry
    

    The volume name returns as dtr-registry-<volume-id>.

  2. Mount the source MSR 2.9.x volume to the MMT container at /storage to provide the container with access to the volume data, for both the Estimate and Extract migration stages.

    Estimate

    docker run \
    --rm \
    -it \
    -v <local-migration-directory>:/migration:Z \
    --mount source=<dtr-registry-id>,target=/storage \
    registry.mirantis.com/msr/mmt:<mmt-version> \
    estimate msr  \
    --source-mke-url <mke-url> \
    --source-username <mke-admin-username> \
    --source-password <mke-admin-password> \
    --source-url <msr-2.9-url> \
    --storage-mode copy \
    --source-insecure-tls \
    /migration
    

    Extract

    docker run \
    --rm \
    -it \
    -v <local-migration-directory>:/migration:Z \
    --mount source=<dtr-registry-id>,target=/storage \
    registry.mirantis.com/msr/mmt:<mmt-version> \
    extract msr  \
    --source-mke-url <mke-url> \
    --source-username <mke-admin-username> \
    --source-password <mke-admin-password> \
    --source-url <msr-2.9-url> \
    --storage-mode copy \
    --source-insecure-tls \
    /migration
    
  3. Obtain the name of the target MSR 3.0 volume.

    kubectl get pvc <instance-name> --template {{.spec.volumeName}}
    
  4. Migrate the data extract to the PVC of the target MSR 3.0.x system. To do this, you must run the MMT container in a Pod with the PVC mounted at the container /storage directory.

    Note

    In the event the PVC is not mounted at the MMT container /storage directory, the Restore migration step may still complete, and the target MSR 3.0.x system may display the restored data in the MSR web UI. Pulling images from the target system, however, will fail, as the source MSR 2.9.x image data is not migrated to the MSR 3.0.x PVC.

    Use the YAML template that follows as an example for how to create the MMT Pod and other required Kubernetes objects:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: <mmt-serviceaccount-name>
    ---
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: <mmt-role-name>
    rules:
      # Add/remove more permissions as needed
      - apiGroups: ["", "apps", "rbac.authorization.k8s.io", "cert-manager.
        io", "acid.zalan.do"]
        resources: ["*"]
        verbs: ["*"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: <mmt-rolebinding-name>
    subjects:
      - kind: ServiceAccount
        name: <mmt-serviceaccount-name>
    roleRef:
      kind: Role
      name: <mmt-role-name>
      apiGroup: rbac.authorization.k8s.io
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: <mmt-pod-name>
    spec:
      serviceAccountName: <mmt-serviceaccount-name>
      volumes:
        - name: storage
          persistentVolumeClaim:
            # This is the PersistentVolumeClaim that the destination/target MSR 3.0.x is using.
            # This PVC is acting as the filesystem storage backend for MSR 3.0.x.
            claimName: <msr-pvc-name>
      containers:
        - name: msr-migration-tool
          image: registry.mirantis.com/msr/mmt:<mmt-image-tag>
          imagePullPolicy: IfNotPresent
          command: [ "sh", "-c", "while true; do sleep 30; done;" ]
          volumeMounts:
          - name: storage
            mountPath: /storage
      restartPolicy: Never
    
  5. Once <mmt-pod-name> is running, copy your source MSR 2.9.x data extract to the /migration location of the MMT container running within the Pod:

    kubectl cp <local-migration-directory> <mmt-pod-name>:/migration
    
  6. Open a shell into the <mmt-pod-name>:

    kubectl exec --stdin --tty <mmt-pod-name> -- sh
    
  7. Perform the Transform step from within the container:

    ./mmt transform metadata msr  \
    --storage-mode copy \
    /migration
    
  8. While still inside the container, perform the Restore migration step.

    ./mmt restore msr \
    --fullname <MSR-3.0.x-Helm-release-name> \
    --storage-mode copy \
    /migration
    
  9. Delete the Kubernetes resources you created for MMT.