delete floating ip via neutron port-delete

Bug #1346932 reported by Joe Talerico
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Invalid
Medium
Elena Ezhova

Bug Description

When running neutron port-delete <floating-ip port> I get a traceback referencing :

2014-07-21 16:34:28.769 31455 TRACE neutron.api.v2.resource DBError: (IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`neutron`.`floatingips`, CONSTRAINT `floatingips_ibfk_2` FOREIGN KEY (`floating_port_id`) REFERENCES `ports` (`id`))') 'DELETE FROM ports WHERE ports.id = %s' ('25c9a306-6f5f-4630-99ec-78893b1e766a',)

Instead of dumping a unhelpful trace to the logs, shouldn't there be a message to the user that they should use the right command to remove the floating IP port?

tags: added: api l3-ipam-dhcp
Changed in neutron:
importance: Undecided → Medium
assignee: nobody → Eugene Nikanorov (enikanorov)
status: New → Confirmed
Elena Ezhova (eezhova)
Changed in neutron:
assignee: Eugene Nikanorov (enikanorov) → Elena Ezhova (eezhova)
Revision history for this message
Joe Talerico (jtaleric) wrote :

Sorry, using OVS plugin, no ML2.

If you run `neutron port delete <fip-port>` it works?

Elena Ezhova (eezhova)
tags: added: ovs
Revision history for this message
Elena Ezhova (eezhova) wrote :

Thank you for clarification!

I switched to OVS plugin, then tried to delete a floating ip port which id I took from a floatingips table (floating_port_id).

But instead of a trace I get a message that delete can not be performed for this port:
Port f3bcdb5c-418c-487a-bb6b-e8cb9585f469 has owner network:floatingip and therefore cannot be deleted directly via the port API.

Revision history for this message
Joe Talerico (jtaleric) wrote :

Unassociate it from a instance, then try to delete the port.

Revision history for this message
Elena Ezhova (eezhova) wrote :

I think that we need to clarify the steps to reproduce the bug.

That's what I do:

1. Create floating ip with no associations
neutron floatingip-create <public_net_id>
2. Delete floating ip port
neutron port-delete <floating_port_id>

I have also tried associating and disassociating a floating ip with ports in private network.

Could you please outline the steps you took?

Revision history for this message
Joe Talerico (jtaleric) wrote :

Elena - sorry! For me :
Create guest, create floating IP, associate floating ip to guest, remove guest, try to delete port.

Revision history for this message
Elena Ezhova (eezhova) wrote :

Joe, I just want to confirm: did you use openvswitch plugin (not ml2 + ovs) with master branch of neutron?

The reason I ask is that:
1. When I use openvswitch plugin I can not even boot an instance, because of the problems with RPC support (see https://bugs.launchpad.net/neutron/+bug/1348226 for details)
2. As you can see in the comments to the bug ^ openvswitch plugin is deprecated as well as linuxbridge and they are going to be removed by the end of Juno.

So, it the answer to my question is yes, I'm afraid this bug would have to be marked as Invalid.

Revision history for this message
Joe Talerico (jtaleric) wrote : Re: [Bug 1346932] Re: delete floating ip via neutron port-delete

Elena,
I am sorry. After working with Rally I didn't look at the env I was pointed at, I just assumed it wasn't ML2. However I looked at the env yesterday, it does have the ml2 plugin using openvswitch.

Joe Talerico
(919) 760-3476

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
- Douglas Adams

> On Jul 25, 2014, at 4:46, Elena Ezhova <email address hidden> wrote:
>
> Joe, I just want to confirm: did you use openvswitch plugin (not ml2 +
> ovs) with master branch of neutron?
>
> The reason I ask is that:
> 1. When I use openvswitch plugin I can not even boot an instance, because of the problems with RPC support (see https://bugs.launchpad.net/neutron/+bug/1348226 for details)
> 2. As you can see in the comments to the bug ^ openvswitch plugin is deprecated as well as linuxbridge and they are going to be removed by the end of Juno.
>
> So, it the answer to my question is yes, I'm afraid this bug would have
> to be marked as Invalid.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1346932
>
> Title:
> delete floating ip via neutron port-delete
>
> Status in OpenStack Neutron (virtual network service):
> Confirmed
>
> Bug description:
> When running neutron port-delete <floating-ip port> I get a traceback
> referencing :
>
> 2014-07-21 16:34:28.769 31455 TRACE neutron.api.v2.resource DBError:
> (IntegrityError) (1451, 'Cannot delete or update a parent row: a
> foreign key constraint fails (`neutron`.`floatingips`, CONSTRAINT
> `floatingips_ibfk_2` FOREIGN KEY (`floating_port_id`) REFERENCES
> `ports` (`id`))') 'DELETE FROM ports WHERE ports.id = %s'
> ('25c9a306-6f5f-4630-99ec-78893b1e766a',)
>
> Instead of dumping a unhelpful trace to the logs, shouldn't there be a
> message to the user that they should use the right command to remove
> the floating IP port?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1346932/+subscriptions

Revision history for this message
Elena Ezhova (eezhova) wrote :

Joe,
I performed the following steps:
1. nova boot --image <image-id> --flavor 1 --nic net-id=<private_net_id> test
2. neutron floatingip-create <public_net_id>
3. neutron floatingip-associate <floatingip-id> <instance_port_id>
4. neutron port-delete <floating_port_id>
Port <floating_port_id> has owner network:floatingip and therefore cannot be deleted directly via the port API.
5. nova delete <instance_id>
6. neutron port-delete <floating_port_id>
Port <floating_port_id> has owner network:floatingip and therefore cannot be deleted directly via the port API.

So, in both cases I'm unable to reproduce the bug. As I have already said, I use branch master.

If I do something wrong, please, correct me.

Revision history for this message
Joe Talerico (jtaleric) wrote :

My plugin.ini config :
[ml2]
# (ListOpt) List of network type driver entrypoints to be loaded from
# the neutron.ml2.type_drivers namespace.
#
# type_drivers = local,flat,vlan,gre,vxlan
type_drivers = vxlan
# Example: type_drivers = flat,vlan,gre,vxlan

# (ListOpt) Ordered list of network_types to allocate as tenant
# networks. The default value 'local' is useful for single-box testing
# but provides no connectivity between hosts.
#
# tenant_network_types = local
tenant_network_types = vxlan
# Example: tenant_network_types = vlan,gre,vxlan

# (ListOpt) Ordered list of networking mechanism driver entrypoints
# to be loaded from the neutron.ml2.mechanism_drivers namespace.
# mechanism_drivers =
mechanism_drivers =openvswitch
# Example: mechanism drivers = openvswitch,mlnx
# Example: mechanism_drivers = arista
# Example: mechanism_drivers = cisco,logger
# Example: mechanism_drivers = openvswitch,brocade
# Example: mechanism_drivers = linuxbridge,brocade

[ml2_type_flat]
# (ListOpt) List of physical_network names with which flat networks
# can be created. Use * to allow flat networks with arbitrary
# physical_network names.
#
# flat_networks =
# Example:flat_networks = physnet1,physnet2
# Example:flat_networks = *

[ml2_type_vlan]
# (ListOpt) List of <physical_network>[:<vlan_min>:<vlan_max>] tuples
# specifying physical_network names usable for VLAN provider and
# tenant networks, as well as ranges of VLAN tags on each
# physical_network available for allocation as tenant networks.
#
# network_vlan_ranges =
# Example: network_vlan_ranges = physnet1:1000:2999,physnet2

[ml2_type_gre]
# (ListOpt) Comma-separated list of <tun_min>:<tun_max> tuples enumerating ranges of GRE tunnel IDs that are available for tenant network allocation
# tunnel_id_ranges =

[ml2_type_vxlan]
# (ListOpt) Comma-separated list of <vni_min>:<vni_max> tuples enumerating
# ranges of VXLAN VNI IDs that are available for tenant network allocation.
#
# vni_ranges =
vni_ranges =10:100

# (StrOpt) Multicast group for the VXLAN interface. When configured, will
# enable sending all broadcast traffic to this multicast group. When left
# unconfigured, will disable multicast VXLAN mode.
#
# vxlan_group =
vxlan_group =224.0.0.1
# Example: vxlan_group = 239.1.1.1

[securitygroup]
# Controls if neutron security group is enabled or not.
# It should be false when you use nova security group.
# enable_security_group = True
enable_security_group = True
firewall_driver=True

Revision history for this message
Joe Talerico (jtaleric) wrote :

Elena, no those are the same steps I have, let me update to see if that helps my current issues.

Revision history for this message
Elena Ezhova (eezhova) wrote :

my ml2_conf.ini was almost the same, when I adjusted some parameters to be the same as yours nothing changed for me:

[ml2]
type_drivers = vxlan
mechanism_drivers = openvswitch
# (ListOpt) List of network type driver entrypoints to be loaded from
# the neutron.ml2.type_drivers namespace.
#
# type_drivers = local,flat,vlan,gre,vxlan
# Example: type_drivers = flat,vlan,gre,vxlan

# (ListOpt) Ordered list of network_types to allocate as tenant
# networks. The default value 'local' is useful for single-box testing
# but provides no connectivity between hosts.
#
tenant_network_types = vxlan
# Example: tenant_network_types = vlan,gre,vxlan

# (ListOpt) Ordered list of networking mechanism driver entrypoints
# to be loaded from the neutron.ml2.mechanism_drivers namespace.
# mechanism_drivers =
# Example: mechanism_drivers = openvswitch,mlnx
# Example: mechanism_drivers = arista
# Example: mechanism_drivers = cisco,logger
# Example: mechanism_drivers = openvswitch,brocade
# Example: mechanism_drivers = linuxbridge,brocade

[ml2_type_flat]
# (ListOpt) List of physical_network names with which flat networks
# can be created. Use * to allow flat networks with arbitrary
# physical_network names.
#
# flat_networks =
# Example:flat_networks = physnet1,physnet2
# Example:flat_networks = *

[ml2_type_vlan]
# (ListOpt) List of <physical_network>[:<vlan_min>:<vlan_max>] tuples
# specifying physical_network names usable for VLAN provider and
# tenant networks, as well as ranges of VLAN tags on each
# physical_network available for allocation as tenant networks.
#
# network_vlan_ranges =
# Example: network_vlan_ranges = physnet1:1000:2999,physnet2

[ml2_type_gre]
tunnel_id_ranges = 1:1000
# (ListOpt) Comma-separated list of <tun_min>:<tun_max> tuples enumerating ranges of GRE tunnel IDs that are available for tenant network allocation
# tunnel_id_ranges =

[ml2_type_vxlan]
vni_ranges = 10:100
# (ListOpt) Comma-separated list of <vni_min>:<vni_max> tuples enumerating
# ranges of VXLAN VNI IDs that are available for tenant network allocation.
#
# vni_ranges =

# (StrOpt) Multicast group for the VXLAN interface. When configured, will
# enable sending all broadcast traffic to this multicast group. When left
# unconfigured, will disable multicast VXLAN mode.
#
vxlan_group = 224.0.0.1
# Example: vxlan_group = 239.1.1.1

[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
# Controls if neutron security group is enabled or not.
# It should be false when you use nova security group.
# enable_security_group = True

[database]
connection = mysql://root:passwd@127.0.0.1/neutron_ml2?charset=utf8

[ovs]
local_ip = 172.18.76.57

[agent]
root_helper = sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf

Revision history for this message
Elena Ezhova (eezhova) wrote :

Could you please post the hash of the last Neutron commit in your tree?

Revision history for this message
Elena Ezhova (eezhova) wrote :

Joe, did the update help you?

Elena Ezhova (eezhova)
Changed in neutron:
status: Confirmed → Incomplete
Revision history for this message
Elena Ezhova (eezhova) wrote :

Joe, since there was no evidence that the bug exists, I mark it as invalid. Please leave a comment if the issue still persists.

Changed in neutron:
status: Incomplete → Invalid
Revision history for this message
Jian Wen (wenjianhn) wrote :

I may reproduce the bug. Here are the steps to reproduce it:

1. create the port with 'service_plugins = router' in neutron.conf
2. delete the port with 'service_plugins = ' in neutron.conf

In neutron/neutron/plugins/ml2/plugin.py, l3plugin.prevent_l3_port_deletion(context, id)
was not called because l3plugin was None. Related code:

    def delete_port(self, context, id, l3_port_check=True):
        LOG.debug(_("Deleting port %s"), id)
        l3plugin = manager.NeutronManager.get_service_plugins().get(
            service_constants.L3_ROUTER_NAT)
        if l3plugin and l3_port_check:
            l3plugin.prevent_l3_port_deletion(context, id)

It's not a bug actually.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.