OCP 3 to 4 migration #17415

ahardin-rh · 2019-10-16T23:29:56Z

Continuation of #16890 t be released in 4.2.z stream next week

openshift-docs-preview-bot · 2019-10-16T23:32:19Z

Preview Build: https://apinnick-app-migration--ocpdocs.netlify.com/openshift-enterprise/latest/migration/migrating-openshift-3-to-4.html

jwmatthews · 2019-10-17T13:15:22Z

modules/migration-adding-replication-repository-to-cam.adoc

+* *Replication repository name*
+* *S3 bucket name*
+* *S3 bucket region*: Required for AWS S3 if the bucket region is not *us-east-1*. Optional for a generic S3 repository.
+* *S3 endpoint*: Required for a generic S3 repository. This is the URL of the S3 service, not the bucket, for example, `http://_<minio-gpte-minio.apps.cluster.com>_`.


We will want to update this to reference an example NooBaa endpoint instead of minio

I am working on other updates to show an example of how to setup the S3 pre-reqs.
Will share later today.

Changed URL to http://s3-noobaa.apps.cluster.com

jwmatthews · 2019-10-17T13:19:55Z

migration/migrating-openshift-3-to-4.adoc

+* You must have `cluster-admin` privileges.
+* You must have `podman` installed.
+* The source cluster(s) must be {product-title} 3.7 or later.
+* The target cluster must be {product-title} 3.9 or later.


Suggest we change to:

"The target cluster is recommended to be the latest released version of {product-title}."

For background...
This will technically work on 3.7 or later for both source and destination.
Recommendation is customer migrate to latest released OpenShift for the destination.

I suggest we leave this as is. We should treat these situations with a support exception.
This will be confusing if you look at this with the lifecycle.

@sferich888 when you say leave as-is, I just want to confirm.

Right now doc says: "The target cluster must be {product-title} 3.9 or later."

I think it should say:
"The target cluster is recommended to be the latest released version of {product-title}."

Then we can address 3->3 migrations on a case-by-case basis. Do you agree?

jwmatthews · 2019-10-17T13:24:53Z

migration/migrating-openshift-3-to-4.adoc

+* You must have `podman` installed.
+* The source cluster(s) must be {product-title} 3.7 or later.
+* The target cluster must be {product-title} 3.9 or later.
+* The replication repository object storage must support the S3 API, for example, Red Hat NooBaa Storage, AWS S3, and generic S3 storage providers.


I assume we need to change "Red Hat NooBaa Storage".

Upstream: NooBaa
Downstream: MCG

For this immediate release we will use upstream NooBaa as an example, after OCS4 releases we will change to leverage an operator for MCG.

I will ask product management for their recommendation of what to call this now.

Confirmed with product management.
Let's change 'Red Hat NooBaa Storage' to 'NooBaa'

Suggest we reword to something like below.

"An object storage provider is required, we refer to this object store as a ‘Replication Repository’. The Replication Repository needs to support the S3 API, for example, NooBaa, AWS S3, and generic S3 storage providers. In addition, the source and destination clusters must both be able to read and write to this object store."

Do we need to call this out as "upstream" and possibly include a note / call out (warning) about support not being provided for upstream projects?

Changed Red Hat NooBaa Storage to NooBaa.

jwmatthews · 2019-10-17T14:07:57Z

migration/migrating-openshift-3-to-4.adoc

+
+* You must have `cluster-admin` privileges.
+* You must have `podman` installed.
+* The source cluster(s) must be {product-title} 3.7 or later.


Add an additional prerequisite

"The migration controller must be able to communicate with both the source and destination clusters, we recommend the migration controller be installed on the destination cluster."

That's a recommendation, not a prerequisite. The default installation is on the target cluster, so I'm not sure it's necessary to mention this. The user would have to go out of their way to install it on another cluster.

eriknelson · 2019-10-17T15:52:30Z

modules/migration-configuring-cors-3.adoc

+
+----
+corsAllowedOrigins:
+- (?i)//migration-openshift-migration\.apps\.cluster\.com(:|\z)


I saw some folks confused by this, thinking literally (?i)//migration-openshift-migration\.apps\.cluster\.com(:|\z) is the string that they should use.

I think prior to "Configuring cross-origin resource sharing on OpenShift Container Platform 3 clusters", we need a section that explains how to get the UI's Origin, and we need to make it clear that the docs will continue with (?i)//migration-openshift-migration\.apps\.cluster\.com(:|\z) as an example Origin, but this value will be different for every user.

You enable communication with the CAM by configuring cross-origin resource sharing on OpenShift Container Platform 3 and 4 (if the OpenShift Container Platform 4 cluster is not hosting the CAM). # Obtaining the UI's Origin First, you must obtain the UI's Origin value to be whitelisted across all of the clusters involved in a migration. 1) You must log into the cluster that is hosting the web UI. 2) The following command will export the encoded `corsAllowedOrigin` for your cluster: `oc get -n openshift-migration route/migration -o go-template='(?i}//{{ .spec.host }}(:|\z){{ println }}' | sed 's,\.,\\.,g'` 3) This output string should be used where an allowed origin must be whitelisted. As an example, we'll use `(?i)//migration-openshift-migration\.apps\.cluster\.com(:|\z)`, but this will differ for your cluster.

The instructions in the upstream README contains a command to obtain the value for the master-config.yaml in this section. https://github.com/fusor/mig-operator/blob/master/README.md#openshift-3. It may be helpful to add similar to the docs.

I've added the steps for obtaining the CAM host URL and marked (?i)//migration-openshift-migration\.apps\.cluster\.com(:|\z) with a callout saying that it needs to be replaced with the user's CAM host URL.

sferich888 · 2019-10-21T14:26:01Z

migration/migrating-openshift-3-to-4.adoc

+* You must have `cluster-admin` privileges.
+* You must have `podman` installed.
+* The source cluster(s) must be {product-title} 3.7 or later.
+* The target cluster must be {product-title} 3.9 or later.


I suggest we leave this as is. We should treat these situations with a support exception.
This will be confusing if you look at this with the lifecycle.

sferich888 · 2019-10-21T14:26:45Z

migration/migrating-openshift-3-to-4.adoc

+* You must have `podman` installed.
+* The source cluster(s) must be {product-title} 3.7 or later.
+* The target cluster must be {product-title} 3.9 or later.
+* The replication repository object storage must support the S3 API, for example, Red Hat NooBaa Storage, AWS S3, and generic S3 storage providers.


Do we need to call this out as "upstream" and possibly include a note / call out (warning) about support not being provided for upstream projects?

xinredhat · 2019-10-22T03:19:03Z

Reviewed, LGTM.

apinnick · 2019-10-22T08:05:18Z

I want to make some updates, so I am forking this branch and will create a new PR.

Have the comments been addressed?

apinnick · 2019-10-22T09:02:35Z

New doc preview: http://file.tlv.redhat.com/~apinnick/ocp-migration-new/migration/migrating-openshift-3-to-4.html

New PR: #17516

ahardin-rh · 2019-10-22T14:51:17Z

@apinnick Looks like you addressed the comments in your new PR, so I will close this PR in favor if your new one.

OCP 3 to 4 migration

aab776b

ahardin-rh added branch/enterprise-4.2 branch/enterprise-4.3 labels Oct 16, 2019

ahardin-rh added this to the Future Release milestone Oct 16, 2019

openshift-ci-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label Oct 16, 2019

jwmatthews reviewed Oct 17, 2019

View reviewed changes

eriknelson suggested changes Oct 17, 2019

View reviewed changes

ahardin-rh self-assigned this Oct 17, 2019

sferich888 suggested changes Oct 21, 2019

View reviewed changes

ahardin-rh closed this Oct 22, 2019

vikram-redhat removed branch/enterprise-4.2 branch/enterprise-4.3 labels Jan 23, 2020

vikram-redhat removed this from the Future Release milestone Jan 23, 2020

OCP 3 to 4 migration #17415

OCP 3 to 4 migration #17415

Uh oh!

Conversation

ahardin-rh commented Oct 16, 2019

Uh oh!

openshift-docs-preview-bot commented Oct 16, 2019 • edited by ahardin-rh Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jwmatthews Oct 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eriknelson Oct 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xinredhat commented Oct 22, 2019

Uh oh!

apinnick commented Oct 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

apinnick commented Oct 22, 2019

Uh oh!

ahardin-rh commented Oct 22, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

openshift-docs-preview-bot commented Oct 16, 2019 •

edited by ahardin-rh

Loading

jwmatthews Oct 17, 2019 •

edited

Loading

eriknelson Oct 17, 2019 •

edited

Loading

apinnick commented Oct 22, 2019 •

edited

Loading