Stack deletion failed for the subnet

[Haiwei Xu]

I am using heat to boot some instances and create a new network , subnet and floatingip using neutron.

But when I delete this stack, I got this error:

2015-03-02 11:23:19.558 INFO heat.engine.resource [-] DELETE: RouterInterface "routerinterface" [c
d123476-962e-4d11-945b-773928a44905:subnet_id=1b43a9f5-d45f-4b43-995e-7c3625b06e81] Stack "wps_sta
ck" [1e63d62f-c397-4304-a53c-159d2532b5d3]
2015-03-02 11:23:19.558 TRACE heat.engine.resource Traceback (most recent call last):
2015-03-02 11:23:19.558 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/resource.py
", line 466, in _action_recorder
2015-03-02 11:23:19.558 TRACE heat.engine.resource yield
2015-03-02 11:23:19.558 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/resource.py", line 887, in delete
2015-03-02 11:23:19.558 TRACE heat.engine.resource
2015-03-02 11:23:19.558 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/scheduler.py", line 295, in wrapper
2015-03-02 11:23:19.558 TRACE heat.engine.resource step = next(subtask)
2015-03-02 11:23:19.558 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/resource.py", line 508, in action_handler_task
2015-03-02 11:23:19.558 TRACE heat.engine.resource yield
2015-03-02 11:23:19.558 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/resources/neutron/router.py", line 361, in handle_delete
2015-03-02 11:23:19.558 TRACE heat.engine.resource self.client_plugin().ignore_not_found(ex)
2015-03-02 11:23:19.558 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/clients/client_plugin.py", line 132, in ignore_not_found
2015-03-02 11:23:19.558 TRACE heat.engine.resource raise ex
2015-03-02 11:23:19.558 TRACE heat.engine.resource Conflict: Router interface for subnet 1b43a9f5-d45f-4b43-995e-7c3625b06e81 on router cd123476-962e-4d11-945b-773928a44905 cannot be deleted, as it is required by one or more floating IPs.

This error does not happen every time when deleting the same stack, and when it happened if running 'stack-delete' command again, the stack can be deleted successfully.

I am not sure this is the same bug with https://bugs.launchpad.net/heat/+bug/1418878

[Sergey Kraynev (skraynev)]

I suppose, that you use juno version where it partially fixed, please look patches:

https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno+topic:bug/1399699,n,z

if it helps you I will mark it as duplicated for one of mentioned in commit messages bugs.

[Haiwei Xu (xu-haiwei)]

Sergey Kraynev

Thank you for your comment. But I am using the latest source, this problem is still remained. I think it's a different bug.

[Sergey Kraynev (skraynev)]

ok, could you please provide template which you use ?
Need to get stable re-produce.

[Haiwei Xu (xu-haiwei)]

This is the template I am using.

[Sergey Kraynev (skraynev)]

Ok. Thx. I will try it.

[Sergey Kraynev (skraynev)]

@Haiwei : thx for the template. I check it and you are right, it's really Heat bug.
We have not check for such definition, when used only network in port's properties.

I will upload fix for it soon, as temporary solution I suggest you to use "fixed_ips" property and set "subnet", instead of network.
Also it's more clear when you create you own subnet, otherwise you will get copies of this port in all subnets assigned on network.

[Steve Baker (steve-stevebaker)]

On 06/03/15 01:12, Sergey Kraynev wrote:
> Also it's more clear when you create you own subnet, otherwise you will get copies of this port in all subnets assigned on network.
Actually I think the port will be assigned to some random subnet when
the network has more than one, which is also not very useful, and makes
it impossible for heat to determine the port -> subnet relationship just
from the template.

Maybe the best we can do here is add documentation to the port network
property to encourage users to specify fixed_ip.subnet instead if known.

[Sergey Kraynev (skraynev)]

> Actually I think the port will be assigned to some random subnet

I have discussed it with one guy from neutron core team. He said, that in current case this port will be created in all subnets, which assigned on network. So it's valid case (honestly I though that it does not work at all :) ) and it's nrcessary to add some validation for it.

> Maybe the best we can do here is add documentation to the port network
property to encourage users to specify fixed_ip.subnet instead if known.

I agree, we should show the right way how to use it.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/167782

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/167782
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=c9f32bfef08e567fda6848686ff6281fa3344c69
Submitter: Jenkins
Branch: master

commit c9f32bfef08e567fda6848686ff6281fa3344c69
Author: Sergey Kraynev <email address hidden>
Date: Fri Mar 27 11:55:14 2015 +1000

    Add dependency for FIP if used network in port

    Change-Id: I4fb108c46c950e588d630d2dcef925ce405b4e34
    Closes-Bug: #1428434