Delete of BGPVPN does not ensure associations are deleted before deletion of BGPVPN itself

[Stamatis Katsaounis]

I am using networking-bgpvpn==7.0.0

The scenario which I am running is the following:

I create a bgpvpn named bgpvpn0
I create a subnet subnet0
I associate the bgpvpn0 to subnet0

I am trying through python neutron client to delete bgpvpn0. Then, I am querying the list of bgvpns until it is gone and, finally, I am deleting the subnet0.

The result is the following:

Error [delete_neutron_subnet(neutron_client, 'dba54c27-efad-4727-96b7-39b388391117')]: Unable to complete operation on subnet dba54c27-efad-4727-96b7-39b388391117: One or more ports have an IP allocation from this subnet

That happens because the port is still present in the subnet due to the aforementioned bgpvpn association.

The solution would be to check for deletion of associations before deleting the bgpvpn.

[Thomas Morin (tmmorin-orange)]

The base behavior for drivers relying on the neutron DB (all drivers except the one for OpenContrail) is that when a BGPVPN is deleted, any Network|Router|Port association for this BGPVPN is deleted from the DB.

I'm not aware of anything in the BGPVPN service plugin that would prevent deletion of any Port|Network|Router resource, even less a subnet resource (subnets are *not* associated to BGPVPNs in BGPVPN API).

That would lead me to believe that the issue you see would be a behavior specific to a driver or to its SDN controller (?) that would create a Port when the association is created, but would fail to delete it when the BGPVPN or association is removed.

Can you provide information about which BGPVPN driver you were using ?

[Stamatis Katsaounis (skatsaounis)]

You are right, my description was not much accurate. I would like to add the following:

I am using Opendaylight driver.
I am creating network net0, subnet net0 and bgpvpn bgvpn0.
I am assigning subnet0 to net0.
I am associating net0 with bgpvpn0.

I am deleting bgpvpn0 and querying the neutron api bgpvn list until it is gone.
I am trying to delete subnet0 and then the error occurs.

The problem is not about deletion of port to subnet0 from Opendaylight. The port is deleted but the process completes later, after the deletion of bgpvpn.

The correct behavior of the bgpvpn deletion would be to *first* confirm that for every network association the bgpvpn object had, the related port becomes deleted. Then, *after* confirming this, the bgpvpn object can be safely deleted.

At my case, I am lucky that my driver deletes the port in the end, although it takes time. What would happen if the driver had left the port as a leftover to the subnet and failing to delete it?

[Thomas Morin (tmmorin-orange)]

> The correct behavior of the bgpvpn deletion would be to *first* confirm that for every network association the bgpvpn object had, the related port becomes deleted. Then, *after* confirming this, the bgpvpn object can be safely deleted.

What is this "related port" ? (where does this "related port" appear in the BGPVPN API ?)

[Stamatis Katsaounis (skatsaounis)]

Hi Thomas,

Thank you for pointing out the "port" I was referring to. Your comment helped me investigate it further. You are right, no port is created to the subnet from bgpvpn side. What I was facing was a leftover from a not-completely-deleted nova instance, which was attached to that subnet, completely irrelevant to bgpvpn.

I am closing this bug report as it is not a bug at all.

Once again thank you for your time and sorry for the inconvenience.

Best regards,
Stamatis