havana to icehouse upgrade (alternative technique)

asked 2015-04-24 05:22:55 -0500

Hi, My current installation (havana): 2 controller (passive HA) 1 network (+ 1 for backup) 12 compute nodes I'm using OVS + GRE with neutron

I need to upgrade to icehouse and i thought an alternative technique. I don't know if it is a stupid technique, so here is the details: Basically i want to install a completely new controller and network node and gradually move the instances from havana to icehouse using snapshots (as suggested here -> http://docs.openstack.org/user-guide/enduser/cli_use_snapshots_to_migrate_instances.html (http://docs.openstack.org/user-guide/...)) The problem is that i have floating ips associated to vms and i cannot modify this floating ips. In particular i have only one external network (say 1.2.3.0/24) and more precisely, the floating ip pool is 1.2.3.10 -- 1.2.3.254. Studying the havana network node, i discovered that 1.2.3.10 (the first ip in the allocation pool) is allocated as a gateway (the qg interface inside the qrouter namespace) when "neutron router-gateway-set" command is used. The important thing here is that 1.2.3.1, the physical router, has 1.2.3.10 -> aa:bb:cc:dd:ee:ff (the "virtual" mac address associated to qg in the qrouter namespace) in the arp table. So when i try to ping 1.2.3.10 from the outside a will reach the havana network node (precisely the qg interface inside the qrouter namespace).

So, if I install a new network node with icehouse and I create a new external network (from the icehouse controller) with a slightly different pool (1.2.3.9 -- 1.2.3.254), I can use 1.2.3.9 as a gateway on this node without ip conflicts. Next, i can migrate gradually all instances ( with a script...) and force icehouse neutron to give a particular floating ip to the instance. Furthermore, i can create private lans on the icehouse environment also with the same ip because this kind of traffic wil be Snatted from iptables on the network node. Can I have an opinion for this idea? I think that if works, it can be great because i can control the downtime and i can move gradually instances with a script. Thanks

edit retag flag offensive close merge delete