Three points to add here:
- neutron should definitely clean up tpi- interfaces from pre-ovn-migration after live migration is complete. Otherwise ovn-controller on the old host will try to claim the subport there too.
- neutron could work around the issue by also setting requested-chassis= on subport to point to the same chassis as the parent. (Though I don't think it will need to do it once the cleanup mentioned above is applied. I also can't guarantee that such change wouldn't affect something else, e.g. introduce race conditions during a switch of a chassis that would now have to be synchronized for both parent and all its subports in a single transaction. Plus that would require a db sync migration rule in neutron maintenance thread to populate the option for all subports. Overall, I don't recommend doing it.)
- it may be argued that ovn-controller should be smart enough to look at parent port requested-chassis field and not claim subports for parent ports that have a different requested-chassis. This is something to be discussed with ovn team to see if there's a reason it's not done already.
Verified on RHOS-17.1-RHEL-9-20230719.n.1 with openstack-neutron-ovn-migration-tool-18.6.1-1.20230518200971.el9ost.noarch
Verified that trunk subports are accessible after trunk vm migration or trunk vm reboot on environment where neutron migrated from ovs to ovn. More than 10 builds already passed without this issue.
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 (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), 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/RHEA-2023:4577