Description of problem: Currently, PENDING_UPDATE and PENDING_CREATE entities cannot be deleted. Please allow a force delete, as the only workaround currently is to connect to the database and run e.g.: ~~~ MariaDB [octavia]> update load_balancer set provisioning_status = 'ACTIVE' where provisioning_status = 'PENDING_UPDATE'; Query OK, 1 row affected (0.37 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [octavia]> ~~~ And then delete those entities once set to ACTIVE. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Account for the fact that entities may be stuck in PENDING and a force delete is needed.
Hi Andreas, Force deletion of LB is not a good idea and is dangerous, it has been discussed upstream in the following story: https://storyboard.openstack.org/#!/story/2002568 We are currently working on solution to mitigate this issue: - Updating timeout values (users may think a load balancer is stuck while timeouts have not expired yet): https://bugzilla.redhat.com/show_bug.cgi?id=1726733 - Avoid unnecessary service restarts on deployment stack update: https://bugzilla.redhat.com/show_bug.cgi?id=1726735 - Graceful shutdown/restart of octavia containers: https://bugzilla.redhat.com/show_bug.cgi?id=1726738
I don't think that this is just a timeout issue: https://bugzilla.redhat.com/show_bug.cgi?id=1712448 https://bugzilla.redhat.com/show_bug.cgi?id=1724798 I ran into these 2 issues above where loadbalancers never left the PENDING state.
RHBZ #1712448 was indeed a bug (already fixed upstream) but it was not leaving resources actually stuck in PENDING_*. It might have given that impression but a closer look showed that there was a bug when an invalid certificate is passed in, the LB was going into ERROR and Octavia after some time tried to repair it. RHBZ #1724798 does not have resources in a transient state (PENDING_*). I had a quick look at the logs yesterday and I could see them in a non-PENDING status. We will triage it there sometime soon.