Comment 0 for bug 1626619

FloatingIPs depend on RouterInterfaces that are on the same subnet that the Port holding the FloatingIP is attached to. (IOW you can't create a FloatingIP until it has some path to get to the outside world via a Router.) Originally this was checked simply by finding the Port resource, then looking through its `fixed_ips` property looking for `subnet` or subnet_id` subproperties that matched the `subnet` or `subnet_id` properties of the RouterInterface.

This changed in https://review.openstack.org/#/c/167782/3/heat/engine/resources/openstack/neutron/floatingip.py to additionally handle the case where the `fixed_ips` property of the Port is not set. In this case we have no way of knowing which subnet the port will land on (depending on whom you believe, it is either assigned to a subnet chosen behind the scenes by Neutron or assigned to _all_ subnets). Therefore in this case we add all RouterInterfaces on any of the Subnets in the same Network.

To do so we make an expensive API call (for every RouterInterface!) to get the list of subnets in the network. This is painful but not crazy, since it's solving a real issue (bug 1428434).

The same patch also attempts to fix the issue with adding too many dependencies during create, unfortunately by causing the opposite problem: not adding _any_ dependencies during create. That kind-of worked prior to convergence, when the dependencies were recalculated for each new stack operation. That mean that stuff would be deleted in the right order. However, under convergence the dependencies are stored in the database as soon as the stack is created, so we will see a recurrence of deletes failing because of missing implicit dependencies.