Bug 1908270 - The 63 characters limitation of route name results in direct volume migration failed
Summary: The 63 characters limitation of route name results in direct volume migration...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Migration Toolkit for Containers
Classification: Red Hat
Component: General
Version: 1.4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 1.4.0
Assignee: Dylan Murray
QA Contact: Xin jiang
Avital Pinnick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-16 09:46 UTC by whu
Modified: 2021-12-02 06:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-11 12:54:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:5329 0 None None None 2021-02-11 12:55:09 UTC

Description whu 2020-12-16 09:46:28 UTC
Description of problem:

Due to there is a 63 characters limitation of route name, this will result in the directvolumemigration-rsync-transfer-route creation failure in target cluster, so the direct volume migration failed.
The route name is composed of "prefix + migplan name + domain". The length of the prefix "directvolumemigration-rsync-transfer-route" is 43, the length of domain + prefix has already more than 63. There still is migration plan name. 63 is too small. 

How reproducible:
always

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


Steps to Reproduce:
1.create any application in source cluster 
$ oc create namespace ocp-55555-nginx-default
$ oc process -p NAMESPACE= ocp-55555-nginx-default -f nginx_with_pv_defaultsc_template.yml | oc create -f -


2. create migration plan for ocp-55555-nginx-default
Just follow common migplan creation process, when enter into "Migration option" phase, checked "Use direct PV migration for filesystem copies" option.

3. trigger migration process

Actual results:
Direct PV migration will failed, the "directvolumemigration-rsync-transfer-route" failed to be created in target cluster

Expected results:
The direct PV migration process should be successfully

Additional info:

In target cluster
$ oc get route -n ocp-55555-nginx-default 
NAME                                         HOST/PORT     PATH   SERVICES                                   PORT   TERMINATION   WILDCARD
directvolumemigration-rsync-transfer-route   InvalidHost          directvolumemigration-rsync-transfer-svc   2222   passthrough   None

$ oc get route.route.openshift.io/directvolumemigration-rsync-transfer-route -o yaml -n ocp-55555-nginx-default
.......
status:
  ingress:
  - conditions:
    - lastTransitionTime: "2020-12-16T08:27:10Z"
      message: 'host name validation errors: spec.host: Invalid value: "directvolumemigration-rsync-transfer-route-ocp-55555-nginx-default.apps.cam-tgt-12730.qe.devcluster.openshift.com": must be no more than 63 characters'
      reason: InvalidHost
      status: "False"
      type: Admitted
    host: directvolumemigration-rsync-transfer-route-ocp-55555-nginx-default.apps.cam-tgt-12730.qe.devcluster.openshift.com
    routerCanonicalHostname: apps.cam-tgt-12730.qe.devcluster.openshift.com
    routerName: default
    wildcardPolicy: None


in source cluster
$ oc get pod -n ocp-55555-nginx-default
NAME                                              READY   STATUS    RESTARTS   AGE
directvolumemigration-rsync-transfer-nginx-html   0/1     Error     0          58m
directvolumemigration-rsync-transfer-nginx-logs   0/1     Error     0          58m
directvolumemigration-stunnel-transfer            1/1     Running   0          58m


$ oc logs directvolumemigration-stunnel-transfer -n ocp-55555-nginx-default
2020.12.16 08:27:39 LOG5[ui]: stunnel 5.56 on x86_64-redhat-linux-gnu platform
2020.12.16 08:27:39 LOG5[ui]: Compiled/running with OpenSSL 1.1.1g FIPS  21 Apr 2020
2020.12.16 08:27:39 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
2020.12.16 08:27:39 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf
2020.12.16 08:27:39 LOG5[ui]: UTF-8 byte order mark not detected
2020.12.16 08:27:39 LOG5[ui]: FIPS mode disabled
2020.12.16 08:27:39 LOG3[ui]: Error resolving "directvolumemigration-rsync-transfer-route-ocp-55555-nginx-default.apps.cam-tgt-12730.qe.devcluster.openshift.com": Neither nodename nor servname known (EAI_NONAME)
2020.12.16 08:27:39 LOG4[ui]: Insecure file permissions on /etc/stunnel/certs/tls.key
2020.12.16 08:27:39 LOG4[ui]: Service [rsync] uses "verifyChain" without subject checks
2020.12.16 08:27:39 LOG4[ui]: Use "checkHost" or "checkIP" to restrict trusted certificates
2020.12.16 08:27:39 LOG5[ui]: Configuration successful
2020.12.16 08:27:39 LOG5[ui]: Binding service [rsync] to :::2222: Address already in use (98)
2020.12.16 08:27:48 LOG5[0]: Service [rsync] accepted connection from 10.128.2.33:58590
2020.12.16 08:27:48 LOG3[0]: Error resolving "directvolumemigration-rsync-transfer-route-ocp-55555-nginx-default.apps.cam-tgt-12730.qe.devcluster.openshift.com": Neither nodename nor servname known (EAI_NONAME)
2020.12.16 08:27:48 LOG3[0]: No remote host resolved
2020.12.16 08:27:48 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2020.12.16 08:27:48 LOG5[1]: Service [rsync] accepted connection from 10.128.2.32:44582
2020.12.16 08:27:48 LOG3[1]: Error resolving "directvolumemigration-rsync-transfer-route-ocp-55555-nginx-default.apps.cam-tgt-12730.qe.devcluster.openshift.com": Neither nodename nor servname known (EAI_NONAME)
2020.12.16 08:27:48 LOG3[1]: No remote host resolved
2020.12.16 08:27:48 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

$ oc logs directvolumemigration-rsync-transfer-nginx-logs -n ocp-55555-nginx-default
2020/12/16 08:27:48 [1] rsync: safe_read failed to read 1 bytes [sender]: Connection reset by peer (104)
2020/12/16 08:27:48 [1] rsync error: error in rsync protocol data stream (code 12) at io.c(276) [sender=3.1.3]
rsync: safe_read failed to read 1 bytes [sender]: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(276) [sender=3.1.3]

Comment 1 whu 2020-12-17 09:43:58 UTC
updated one information, 

The 63 characters limitation just include the length of prefix "directvolumemigration-rsync-transfer-route-"  + namespace.  the length of prefix is 44, so the length of namespace can not be more than 19.  
But in customer 's environment, it is possible to have a namespace which is more than 19 characters.

Comment 2 Dylan Murray 2021-01-12 15:25:52 UTC
https://github.com/konveyor/mig-controller/pull/883

Comment 3 Dylan Murray 2021-01-13 17:40:45 UTC
https://github.com/konveyor/mig-controller/pull/886

existing PR has some compatibility issues. This PR will allow for a 59 character namespace. We will add some validation around this with a backdoor in the operator to enable a 63 char namespace.

Comment 6 Dylan Murray 2021-01-18 13:54:19 UTC
https://github.com/konveyor/mig-controller/pull/897

Comment 7 Dylan Murray 2021-01-18 14:18:57 UTC
https://github.com/konveyor/mig-operator/pull/552

Comment 12 Sergio 2021-01-25 13:00:15 UTC
Verified using MTC 1.4.0. AWS 3.11 -> AWS 4.5 (AWS S3)

openshift-migration-rhel7-operator@sha256:79f524931e7188bfbfddf1e3d23f491b627d691ef7849a42432c7aec2d5f8a54
    - name: MIG_CONTROLLER_REPO
      value: openshift-migration-controller-rhel8@sha256
    - name: MIG_CONTROLLER_TAG
      value: cdf1bd56e353f076693cb7373c0a876be8984593d664ee0d7e1aeae7a3c54c1f


Namespaces with length 59 are migrated properly. Namespaces with length bigger than 59 show an error in the dvm route.


Moved to VERIFIED status.

Comment 14 errata-xmlrpc 2021-02-11 12:54:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Migration Toolkit for Containers (MTC) tool image release advisory 1.4.0), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5329


Note You need to log in before you can comment on or make changes to this bug.