Comment 1 for bug 1834045

1) I am very glad multiple port binding is being considered for use by networking-ovn.

2) It is true that during implementation the existence of agents was assumed. That wasn't an oversight. A careful read of the spec shows that the functionality was specified for an agents based implementation. To confirm this, just look at the state diagram here: https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/portbinding_information_for_nova.html#activate-rpc-port-update-delete. In that sense, instead of a bug, this should be seen as "Multiple Port Bindings Phase II"

3) From the Neutron implementation perspective, it was never assumed that Nova was going to use the 'network-vif-plugged' event to move to the actual migration stage. That is a decision that was made on the Nova side. In Neutron the only assumption that was made (according to the spec) was that Nova would request the creation of an inactive binding and that upon the completion of it, Nova would proceed with the migration. I agree that the chosen way seems odd.

4) It maybe the case that Neutron agent in the source host is sending a port UP message. That is more an oversight than anything else. During implementation of multiple port binding, the strategy was to be as least intrusive as possible with what was already in place. This strategy was adopted given the fact that port binding is such a fundamental Neutron functionality. Having said that, I don't think the agent sending port UP is the major issue in this bug report. While we may optimize it, it is irrelevant from the point of view of OVN, since OVN doesn't have agents. The core of the issue is how to communicate with Nova properly once the inactive binding has been created, so the migration can continue