[network] cookbook does not move ip from interface to bridge

[Wei Hu]

The l3-agent recipe does not move the ip from external interface to external bridge,
which will let the network node lost external network connection.

E.g.
If the external interface is eth1 which has 10.6.12.10,
after run the l3-agent recipe, an external bridge "br-ex"
is created which plugged the eth1. But the eth1 still has
the ip, meanwhile, br-ex don't have any ip. This cause the
node lost the external network connection.

[Mark Vanderwiel (vanderwl)]

Moving the ip might be a bit of work and need a blueprint to handle the complexity.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/177581

[Wei Hu (huwei-xtu)]

@Yuki Nishiwaki, I'm sorry.
But I think temporary move ip address is very dangerous. Since this move will lose efficacy once user reboot os or restart network. Which means once user reboot os or restart network, the ip address can not be accessed any more. However, to a linux server, losing network connection almost means losing its control.
And actually, we did some more about ip movement by modify linux network configuration files. And plan to write a blue print to track those complexity steps. Do you mind to implement it together ?

[Wei Hu (huwei-xtu)]

I have draft a BP.
See https://blueprints.launchpad.net/openstack-chef/+spec/ip-movement

[Yuki Nishiwaki (uckey-1067)]

@Wei Hu , Thanks for your comment.
I see. You are right.
I have been thinking only situation of having multi-nic. . . .
If we use server which have single-nic, the issue you say appear.

I want to ask you about what you say.

>And actually, we did some more about ip movement by modify linux network
Do you have the patch for "moving ip" already ?

>configuration files. And plan to write a blue print to track those
>complexity steps. Do you mind to implement it together ?
It's good idea!!
But I don't know how to develop.
The patch (https://review.openstack.org/177581) will be aborted and create new patch by you?

[Wei Hu (huwei-xtu)]

Thanks.
Actually, we have patch for ip movement, and is ready for rhel product environment. But need more development for ubuntu(we also have finished ubuntu platform recips, but not test enough).
The implement steps can be summary by:
1. Back up relate network configuration files(e.g. rhel ifcfg-eth0, resolv.conf)
2. Modify the network configuration files. You can reference to http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=rhel/README.RHEL;hb=HEAD for rhel. And http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=debian/openvswitch-switch.README.Debian;h=8617e77103eadb55a5083de6400efde53109b29e;hb=HEAD for ubuntu.
3. Let those configurations take effect.
4. Roll back if move failure.

We plan to contribute this patch to community, I'm very glad if you can provide your opinions or comments to our patch to implement it together. :-)
Thanks.

[Yuki Nishiwaki (uckey-1067)]

Thanks for your instruction.
I think I want to cooperate it. So I wait for you to upload Gerrit. I'm looking forward to your patch.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Yuki Nishiwaki (<email address hidden>) on branch: master
Review: https://review.openstack.org/177581

[Wei Hu (huwei-xtu)]

Thanks @Yuki Nishiwaki.

[Petr Michalec (epcim)]

Moving ip from interface to bridge alternative. As I know the current approach is to create resources in chef cookbooks to properly configure OS configuration to make the movement pernament.

I propose an alternative, or an temporary alternative, to make wheels running before finally reoslved. I propose an multiplatform solution - just call an "up" script when the ext interface is initialized. So when the networking/interface is started/restarted the up script is being called.

For ubuntu example:

auto eth0
iface eth0 inet static
address 10.10.51.60
netmask 255.255.255.0
gateway 10.10.51.1
metric 0
up /etc/neutron/move_ip.sh

with the content (copy paste from chef file template):
        iface_cidr=`ip addr show dev #{ext_bridge_iface} scope global |awk '/inet/ {print $2}'`

        # recreate the bridge
        ovs-vsctl br-exists #{ext_bridge} || ovs-vsctl add-br #{ext_bridge} -- add-port #{ext_bridge} #{ext_bridge_iface}

        # MOVE IP ADDR
        ip addr flush #{ext_bridge_iface}
        ip addr add ${iface_cidr} dev #{ext_bridge}
        ip link set #{ext_bridge} up

        # in my case I actually lost orig iface IP + manually set default route so I do have to re bind:
        ip addr add 10.10.51.0/24 dev eth0
        ip ro add default via 10.10.51.2 dev br-ext

[Dr. Jens Harbott (j-harbott)]

Closed as there has been no activity in years. Please create a new bug if this issue still affects you.