OS::Neutron::FloatingIP is missing hidden dependencies
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Fix Released
|
High
|
Zane Bitter | ||
Newton |
Fix Committed
|
Undecided
|
Rabi Mishra |
Bug Description
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:/
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.
The solution here is to change it back to depending on all RouterInterfaces at create time, instead of none of them.
See further discussion in https:/
description: | updated |
Changed in heat: | |
assignee: | nobody → Oleksii Chuprykov (ochuprykov) |
tags: | removed: newton-backport-potential |
I raised bug 1626634 for the issue of paring this back again to the minimum number of dependencies that we need, and getting rid of the RPC call.