Comment 10 for bug 1456073

Oleg in my opinion, the right time to create the floatingip infrastructure would be before the vm actually migrates and is planning to migrate.

1. If we get the "future_host" for migration information from the nova, we can prepare the host for the fip migration - like
       Create Router namespace
       Create FIP namespace
       Associate the Router and FIP Namespace.
      I have made some headway with this on this patch.
     https://review.openstack.org/#/c/259171/

2. In order for this to be there, we have to track the port with respect to the "old_host", "cur_host" and "new_host" or "future_host".
   For this I would suggest that we make changes to the port-binding table to handle all "host" changes.
  In this case the old_host and the cur_host can be the same. The new_host denotes where the port is intended to move. Once we get this information, the server can pre-populate the details and send it to the agent to create the fip namespace.
  In order to address this I have already created a patch.
  https://review.openstack.org/#/c/259299/

3. The thing that we need more should we need to have a different type of "event_notifier" such as "MIGRATE_START" or "MIGRATE_END" for the port, or else are we going to make use of the same "UPDATE_PORT", "BEFORE_UPDATE" for this. -- This should be considered.

4. With all this infrastructure, when "NOVA" provides us a notification before "pre-migration" to setup the L3, then we can go ahead and create it.

5. If there are any other issues on the neutron side, we can notify 'NOVA" that network-is-not-ready for migration and NOVA should take necessary action.

6. If everything is fine, we send a "OK" message, and NOVA will proceed with the migration.

7. If NOVA errors out, it should send a reply back to us and about its state and we should revert the state on our side.

Please let me know if you have any other questions.