Comment 7 for bug 1626619

Reviewed: https://review.openstack.org/394814
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=ae3b079a46811663d20998e8b5d31ad79f3242db
Submitter: Jenkins
Branch: stable/newton

commit ae3b079a46811663d20998e8b5d31ad79f3242db
Author: Zane Bitter <email address hidden>
Date: Fri Nov 4 16:06:43 2016 -0400

    Make FloatingIP depend on all RouterInterfaces again

    It used to be that a FloatingIP would depend on all RouterInterfaces that
    it couldn't determine were on a different subnet to the port the FloatingIP
    was attaching to (by virtue of the Subnet value being None in both cases,
    and therefore matching). That changed in
    c9f32bfef08e567fda6848686ff6281fa3344c69 to depending only on
    RouterInterfaces that it *could* determine *were* in the same subnet. This
    resulted in no dependency being added at create time when the Subnet was a
    resource in the local stack (as opposed to being passed in e.g. as a
    parameter).

    That caused problems with some Neutron plugins, but worked with others
    where the dependencies were required only at delete time (at this point the
    in-template Subnets had IDs and therefore the dependencies were fully
    determined). However, with convergence phase 1 enabled, the dependencies
    calculated at create time are used throughout the lifecycle of the stack,
    thus causing non-deterministic ordering problems at delete time.

    This patch restores the behaviour where if the Subnet for a RouterInterface
    cannot be determined, the FloatingIP will depend on it. It also corrects a
    bug where we only checked the first Subnet if multiple Networks/Subnets
    were listed for the port.

    Change-Id: I185e30b2247c5b423d319506f60864c3027fc4fe
    Closes-Bug: #1626619
    (cherry picked from commit d5ef455f660d342f4eb8e2a5a9531d4fc30ac25c)