[BUG] Attached floating IP is not released when the EWCCLI deletes an intance

[slothkong]

Affected Command

ewc infra delete

Describe the issue

When using the EWCCLI to cleanup after deploying an Item (technology: "Ansible Playbook") with an optional external IP address from, the external floating IP address that was attached to the underlying VM remains locked, even when the VM is successfully teared down.

Steps to Reproduce

1. Deploy any Item, e.g. ewc hub deploy ssh-bastion-flavour --external-ip
2. Tear down the Item (and its underlying VM) by running ewc infra delete ssh-bastion-flavour

Expected Behavior

Not only the VM is deleted, but the dangling floating ip is released right away as to not cause confusion or consume unnecessary quotas.

Logs or Output

Environment

Linux

EWC CLI Version

main (216a50a297f08e3d274d2e019a9add8fb9dfac97)

[slothkong]

@pacospace , please note that this is not a critical issue at the moment. For the test automation, I have ensured the GitHub action cleans up where the EWCCLI does not, so as to not get blocked after a few test batches.

However, I think users would benefit from this edge case being patched. At the moment, it is very easy to unconsciously litter a tenancy with reserved Floating IPs that cannot be released/reused without technical understanding and manual intervention via the OpenStack CLI.

[pacospace]

what do you mean by releasing the floating IP? can you add more info on how you see that the floating IP is not released please? The delete command is simply deleting the VM as you do from openstack, if the VM is deleted the interface doesn't exist and the floating IP is no more assigned in Openstack. But of course it remains as existing in Openstack. I don't understand where would it be locked if the VM and the interface is gone (once VM is deleted). I need more info. Thank you for opening the issue @slothkong

[slothkong]

Hi again @pacospace,

After deleting the VM which has a floating IP attached, via EWCCLI, you can list the reserves floating IPs in a machine-friendly format by running:

openstack floating ip list -f json

In the payload, you should see the same IP that belonged to the VM.

It will show up, just like any other IP currently in use, but with the "Fixed IP Address" attribute is set to null.

To "unlock" it and avoid quota limits when automatically provisioning new ones, you can run:

openstack floating ip delete <ipv4 address>

Hope that clears things up.

[pacospace]

but this is the same behaviour of Morpheus actually :D if you deploy a new VM will first try to use an existing floating IP and if missing it will request a new one. I see your point to keep it clean, but not sure if we need to clean it from the ewccli, openstack will assign an existing one first when you request a floating IP to my knowledge, if the user hits the limit, all floating IPs means are associated to an interafece, so to an existing VM.

[slothkong]

@pacospace ,regarding your comment about Morpheus:

if you deploy a new VM will first try to use an existing floating IP and if missing it will request a new one.

I was not aware it was be so well behaved as to attempt said fallback approach.

Regardless, when going one step lower in the abstraction layers and interacting with OpenStack directly, I believe this statement needs to be revised:

openstack will assign an existing one first when you request a floating IP

There has been several occasions during Item development, where dangling floating IPs caused runtime errors. It might be simply that our Terraform module does not implement a fallback, and instead attempts to create a new Floating IP on every VM provisioning, while removing it together with the VM tear down; that is also a valid approach.

At any rate, I hit the issue so often in the past that I added an entry for it in the Items troubleshooting documentation. More recently, the issue popped up again while working on the EWCCLI Test Automation. Hence, the GitHub action is getting a patch to deal with those "orphan" floating IPs.