Bug 2074819

Summary: Change description of state migration in MTC documentation
Product: Migration Toolkit for Containers Reporter: Richard Hoch <rhoch>
Component: DocumentationAssignee: Richard Hoch <rhoch>
Status: CLOSED CURRENTRELEASE QA Contact: ssingla
Severity: medium Docs Contact: Richard Hoch <rhoch>
Priority: medium    
Version: 1.7.0CC: akarol, ernelson, mberube, ssingla, xjiang
Target Milestone: ---Flags: rhoch: needinfo?
Target Release: 1.7.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-18 14:49:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Richard Hoch 2022-04-13 07:38:12 UTC
Description of problem: Documentation aspect of https://bugzilla.redhat.com/show_bug.cgi?id=2072186 


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Richard Hoch 2022-04-18 07:20:49 UTC
Marco -- Section 8.2.5 of the MTC documentation ("Running a migration plan in the MTC web console")  https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html-single/migration_toolkit_for_containers/index#migration-running-migration-plan-cam_migrating-applications-with-mtc  has note after stage 2 that says "IMPORTANT: Do not use state migration to migrate a namespace between clusters. Use stage or cutover migration instead."  Is that still correct for the web console or should I remove it and adjust the definition of "state" there (add that you can migrate between clusters, as well as removing the reference to Kubernetes resources)?

Comment 2 Erik Nelson 2022-04-20 17:29:00 UTC
I don't know what the intention of this note was when it was originally added.

> ...migrate a namespace between clusters

This isn't specific enough to mean anything of value. If I read between the lines, I *think* what this is saying is that you should use stage/cutover to "migrate your workloads, including their state, on a namespace basis". The significance here is that the user needs to understand that in order to migrate the application itself (it's k8s objects), the images, AND the state, they need to use stage and cutover. If they only care about migrating data because their workload's deployments are managed by a CD system like Argo, they should use state only migration to get their data transferred to their new destination.

When doing a state only migration, it is not possible to migrate k8s resources that could be considered application state (like secrets/configmaps) as well as PVCs. You need to adjust the MigPlan on the cli to include the k8s resources.

So to try to answer your question, I think this NOTE should remain, and that "migrate a namespace between clusters" needs more specificity. I will also defer to Marco however, and I'm trying to provide the context here as best as I can.

Comment 3 Marco Berube 2022-04-20 17:59:37 UTC
please change doc to:

State copies selected persistent volume claims (PVCs) 

instead of :

State copies selected persistent volume claims (PVCs) and Kubernetes resources that constitute an application’s state. You can use state migration to migrate a namespace within the same cluster.


(Even if the current version could be technically correct, it's misleading.   Most people at this point just want to know what state only migrate PVCs).

Comment 4 Richard Hoch 2022-05-09 10:36:39 UTC
Marco.

Please review thids PR: https://github.com/openshift/openshift-docs/pull/44543

Comment 5 Marco Berube 2022-05-16 11:05:51 UTC
Looks good. thanks.

Comment 6 Richard Hoch 2022-05-16 11:09:18 UTC
Aziza or Xin,

Please review this PR: https://github.com/openshift/openshift-docs/pull/44543

Comment 7 Aziza Karol 2022-05-16 14:03:22 UTC
Sachin, Please Review

Comment 8 Richard Hoch 2022-05-18 14:49:34 UTC
Merged.