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.
Reviewed: https:/ /review. openstack. org/393922 /git.openstack. org/cgit/ openstack/ heat/commit/ ?id=d5ef455f660 d342f4eb8e2a5a9 531d4fc30ac25c
Committed: https:/
Submitter: Jenkins
Branch: master
commit d5ef455f660d342 f4eb8e2a5a9531d 4fc30ac25c
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 e567fda6848686f f6281fa3344c69 to depending only on faces that it *could* determine *were* in the same subnet. This
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
c9f32bfef08
RouterInter
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: I185e30b2247c5b 423d319506f6086 4c3027fc4fe
Closes-Bug: #1626619