fip router config is not created if the vm ports attached to FIPs have no device_owner

[Miguel Angel Ajo]

With dvr_snat or dvr mode, if you create a port like described, and then attach it to
a netns in any of the computes or dvr_snat node, the _floatingips key is not set
by neutron-server on a sync_routers call from l3-agent.

This leads to the FIP namespace not being updated for the specific floating ip, or
not even being created.

We either document that a valid device_owner is necessary[1] for a floating-ip in DVR,
or we accept an empty device owner.

I believe we should accept an empty device_owner to don't differ from the non-DVR implementation.

Script to reproduce:

neutron net-create dmz

ID_DMZ=$(neutron subnet-create dmz --name dmz_subnet 172.16.255.128/26 | awk '/ id / { print $4 }')
neutron port-create --name dmz-vm1 dmz --fixed-ip subnet_id=$ID_DMZ,ip_address=172.16.255.130 --binding:host_id=$(hostname)

ID_DMZ_NET=$(neutron net-show dmz | awk ' / id / { print $4 }')

DMZ_VM1_MAC=$(neutron port-show dmz-vm1 | awk ' / mac_address / { print $4 } ')
DMZ_VM1_ID=$(neutron port-show dmz-vm1 | awk ' / id / { print $4 } ')

sudo ip netns add vm1
sudo ovs-vsctl -- --may-exist add-port br-int vm1 \
               -- set Interface vm1 type=internal \
               external_ids:attached-mac=$DMZ_VM1_MAC \
               external_ids:iface-id=$DMZ_VM1_ID \
               external_ids:vm-id=vm-$DMZ_VM1_ID \
               external_ids:iface-status=active external_ids:owner=admin

sudo ip link set vm1 address $DMZ_VM1_MAC

sudo ip link set vm1 netns vm1
sudo ip netns exec vm1 ip link set dev vm1 up
sudo ip netns exec vm1 dhclient -I vm1 --no-pid vm1
sudo ip netns exec vm1 ip addr show
sudo ip netns exec vm1 ip route show

neutron router-create router_dmz
neutron router-gateway-set router_dmz public
neutron router-interface-add router_dmz dmz_subnet

FIP_ID=$(neutron floatingip-create public | awk '/ id / { print $4 }')
FIP_IP=$(neutron floatingip-show $FIP_ID | awk '/ floating_ip_address / { print $4 }')
neutron floatingip-associate $FIP_ID $DMZ_VM1_ID

[1] https://github.com/openstack/neutron/blob/f2235b7994b22d3e4be72185b86ba5723352f4b0/neutron/common/utils.py#L227

[Brian Haley (brian-haley)]

I think this is more of a documentation issue to make sure these ports have a "compute:" prefix on them.

[lizhixin (lizhixin3016)]

I agree with Brian Haley.

[Armando Migliaccio (armando-migliaccio)]

I don't understand what you are trying to do: why are you manipulating low-level mechanisms in a way that no users would do? Is this even a genuine bug?

I don't believe that from an implementation standpoint an internal component should look at the port's device owner to apply policies, and as such I'd rather see a bug where we attempt to break this dependency. In fact, as something that can be provided by the user this is obviously rather error prone. That said, no user should really fiddle with device owner directly. The fact that nova does it, it's already bad enough and we are trying to put a stop on it allowing services to tag their resources the way they see fit.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]