[Openstack] Upgrade nova-network without downtime?

Andrew Bogott abogott at wikimedia.org
Wed Jul 29 17:08:07 UTC 2015


On 7/29/15 6:06 AM, Vijaya Bhaskar wrote:
> If you can add additional compute nodes, then create networks in 
> neutron with the same network range as nova-network and then migrate 
> the VMs from old compute node to new compute nodes with neutron support.
That is an inventive but Extremely Complex suggestion :)  Neutron 
doesn't support my current network topology so I'm not really interested 
in switching... I just want want to move from one nova-network node to 
another.  (It doesn't help that block migration is sort of broken in 
Icehouse.)

-A


>
> On Wed, Jul 29, 2015 at 12:02 AM, Andrew Bogott <abogott at wikimedia.org 
> <mailto:abogott at wikimedia.org>> wrote:
>
>     I'm running Icehouse with the 'legacy' nova-network service and a
>     single network node.
>
>     Everything in my cluster is running Ubuntu Trusty and ready for an
>     upgrade to Juno, except for my network node, which is still
>     running Precise.  How do I upgrade it without causing cloud-wide
>     downtime? I can think of a few approaches, none of which I feel
>     confident about undertaking:
>
>     1: Build a new network node running Trusty, and then nudge
>     existing VMs off of the old node and onto the new one.  I've
>     gotten fairly far down this path, but just realized that I don't
>     have any idea how to do the 'nudge' step.
>
>     2: Switch my network to multi-node mode, add a new network node,
>     somehow inform VMs about the new secondary node, then upgrade and
>     reboot network nodes one at a time and rely on the instances to
>     fail over to the running node during upgrade.
>
>     3: Stop having special-purpose network nodes altogether and adopt
>     the (more-modern, as I understand it) approach of running
>     nova-network on each compute node.  This seems ideal in the long
>     run, but also maximize the amount of tinkering and potential disaster.
>
>     Has anyone done this?  #2 seems like the obvious approach since it
>     gets me some redundancy in the long run, but I'm not at all clear
>     on what the steps are given an already-running-and-useful
>     network.  I have the feeling that I've read a guide about
>     upgrade-via-migration which would closely resemble #1 but I can no
>     longer find that document.
>
>     Thank you!
>
>     -Andrew
>
>
>     _______________________________________________
>     Mailing list:
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>     Post to     : openstack at lists.openstack.org
>     <mailto:openstack at lists.openstack.org>
>     Unsubscribe :
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150729/4c5eae88/attachment.html>


More information about the Openstack mailing list