It appears that the route name breach of 63 chars has been reintroduced as a regression. This is something that has been addressed with several bugfixes in the past: https://bugzilla.redhat.com/buglist.cgi?list_id=12252611&product=Migration%20Toolkit%20for%20Containers&query_format=advanced&short_desc=63%20char&short_desc_type=allwordssubstr ==== The dvm route created by MTC tool for PVC rsync during stage step has different naming in MTC 1.6 compared to 1.5. For project with long name the dvm route is failing to admit in MTC 1.6 because of the length is greater than 63 characters: Example: Project Name: longnameprojecttest-longnameprojecttest-longnameprojecttest-123 DVM route host in MTC 1.5: dvm-ccc13e60be2e90aec3f16fb07a0d928b.mycorp.com DVM route host in MTC 1.6: dvm-longnameprojecttest-longnameprojecttest-longnameprojecttest-123.apps.mycorp.com Error: host name validation errors: spec.host: Invalid value: "dvm-longnameprojecttest-longnameprojecttest-longnameprojecttest-123.apps.mycorp.com": must be no more than 63 characters
For some reason the bot didn't kick this to MODIFIED after the PRs were merged to the release branches. Manually moving to MODIFIED based on: https://coreos.slack.com/archives/C018T5LD33M/p1638309163068100
On Verifying with the latest 1.6.3 build, openshift-migration-operator-metadata-container-v1.6.3-9 DVM route not taking the hash and the migration fails again. Moving to Assigned state.
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 (Moderate: Migration Toolkit for Containers (MTC) 1.6.3 security and bug fix update), 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/RHSA-2022:0202