Bug 1656061 - Heat stack failed to delete - need to remove router's subnet ports before trying to remove the subnet
Summary: Heat stack failed to delete - need to remove router's subnet ports before try...
Keywords:
Status: CLOSED DUPLICATE of bug 1652453
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.11.0
Hardware: All
OS: All
high
high
Target Milestone: ---
: ---
Assignee: Luis Tomas Bolivar
QA Contact: Udi Shkalim
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-04 15:04 UTC by Udi Shkalim
Modified: 2018-12-11 13:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-11 13:06:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Udi Shkalim 2018-12-04 15:04:58 UTC
Description of problem:
Setup is Openshift on OpenStack as a tenant.
Part of the openshift installation there is a provisioning playbook that creating a heat stack with all of openshift nodes and networks... https://github.com/openshift/openshift-ansible
When trying to uninstall the heat stack (a.k.a - delete) we have the following failure - 

Failed to delete stack openshift.example.com: Resource DELETE failed: BadRequest: resources.pod_subnet_pool: Unable to delete subnet pool: Subnet pool has existing allocations.
Neutron server returns request_ids: ['req-0996943e-e6a7-4af1-87b7-4bfcafba2508']

When deleting the subnets manually from the router it seems to work.

Version-Release number of selected component (if applicable):
python-heat-agent-1.7.1-0.20180907213355.476aae2.el7ost.noarch
python-heat-agent-ansible-1.7.1-0.20180907213355.476aae2.el7ost.noarch
heat-cfntools-1.3.0-2.el7ost.noarch
openstack-heat-agents-1.7.1-0.20180907213355.476aae2.el7ost.noarch
puppet-heat-13.3.1-0.20181013123446.1c5d32f.el7ost.noarch
python2-heatclient-1.16.1-0.20180810081134.b5f3d34.el7ost.noarch
python-heat-agent-hiera-1.7.1-0.20180907213355.476aae2.el7ost.noarch
python-heat-agent-docker-cmd-1.7.1-0.20180907213355.476aae2.el7ost.noarch
python-heat-agent-apply-config-1.7.1-0.20180907213355.476aae2.el7ost.noarch
python-heat-agent-puppet-1.7.1-0.20180907213355.476aae2.el7ost.noarch
python-heat-agent-json-file-1.7.1-0.20180907213355.476aae2.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Deploy osp14 
2. run the openshift-ansible as a tenant
3. after installation is done try to delete the heat stack

Actual results:
Delete failed

Expected results:
Delete finish without errors

Additional info:

Comment 2 Luis Tomas Bolivar 2018-12-05 07:48:20 UTC
@Udi: Did you try to remove the stack with 'openstack stack delete ...'? Is this deployment using Kuryr? The right way to remove the stack installed with openshift-ansible playbooks is to also use the provided uninstall playbook. Note there are several resources created by Kuryr (for instance subnets for the namespaces) that were not created by the initial heat template, so stack delete will fail to delete those (as it is not aware of them)

Comment 3 Udi Shkalim 2018-12-05 09:27:10 UTC
(In reply to Luis Tomas Bolivar from comment #2)
> @Udi: Did you try to remove the stack with 'openstack stack delete ...'? Is
> this deployment using Kuryr? The right way to remove the stack installed
> with openshift-ansible playbooks is to also use the provided uninstall
> playbook. Note there are several resources created by Kuryr (for instance
> subnets for the namespaces) that were not created by the initial heat
> template, so stack delete will fail to delete those (as it is not aware of
> them)

Thanks for the information. Yes the deployment is using kuryr.
I'm running the uninstall playbook.

Comment 4 Luis Tomas Bolivar 2018-12-10 14:58:49 UTC
Then, I don't think this belongs to heat, but to openshift-ansible uninstall playbook

Comment 5 Luis Tomas Bolivar 2018-12-10 15:05:04 UTC
It would be great to have information about the resources that were not deleted with the uninstall playbook, and the tasks that failed (if any)

Comment 6 Udi Shkalim 2018-12-11 12:16:04 UTC
It was an openshift-ansible issue that was resolved by - https://github.com/openshift/openshift-ansible/commit/e8727c80edf9dd056e42d8b705235e46e480ec1a
Should we keep it for downstream tracking? We cherry-picked this patch to our infrared openshift plugin - https://code.engineering.redhat.com/gerrit/#/c/158044/
Should we backport it to ansible 3.11/10 as well?

Comment 7 Luis Tomas Bolivar 2018-12-11 13:06:41 UTC
The problem of the double domain name is covered on this bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1652453

So, I'm closing this one as a duplicate of it

*** This bug has been marked as a duplicate of bug 1652453 ***


Note You need to log in before you can comment on or make changes to this bug.