openstack team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On 24 May 2013 22:39, Maciej Gałkiewicz <maciejgalkiewicz@xxxxxxxxxxxxx> wrote:
> Hi
>
> I am currently using grizzly with nova-network (flat dhcp network without
> vlans). I have tried to migrate to quantum without breaking my instances but
> it is not so trivial. Could you please point out some howtos/manuals or at
> least let me know whether it is actually possible?
>
> I can replace old instances with new ones but during the migration all of
> them must have network connectivity. I would like to avoid migrating data
> from nova to quantum database. Replacing instances is probably easier for
> me.

You ability to replace instances makes this pretty easy.

You'll want a new OpenStack Network network node, which will supply
your exterior routing, metadata proxy and l3 routing. If possible pick
new interior network ranges, if thats not possible, mark a good
selection - say 10 or 20 - ips in your nova network setup as reserved
(you need to use sql to do this AFAICT). Then only permit those as
your allocation pool.

Start by getting that setup per the various docs. Then spin up a
*test* nova-compute node [doesn't have to be full-size] and configure
it to match - be sure to set the firewall driver and security group
implementation in nova, and to enable the security group
implementation in the ovs plugin. The defaults in G are still to use
nova itself for these things.

You can tell it's working when you can deploy an instance on that test
node (e.g. you might make it a region or cell to partition it out, or
at least provide scheduler hints), and you can:
 - get to the metadata server from it
 - traffic from it outside the cloud gets NATted when you want it to
be (and not when you don't)
 - you can allocate a floating IP to it's port, and after adding port
22 to it's security group, ssh into it.
 - you can reach your existing cloud instances from it
 - they can reach it.

Once you have that, make a second test nova-compute node, and test
inter-instance traffic for instances between those two nodes.

Once *that* is working, you're ready to migrate: disable your test
nodes. Disable the least loaded of your production nova-compute nodes
and evacuate it - either by spinning up enough new instances, or live
migration, or whatever. Once you've evacuated a nova-network using
server entirely, redeploy it with the new setup.

Now, disable all your legacy config nova compute nodes, so all new
deploys go to the newly configured node.

Pick your next least-loaded node, and evacuate it the same way.

Rinse and repeat until you have no nova-network configured compute
nodes, then tear down the nova-network service and any other legacy
cruft.

HTH,
Rob

-- 
Robert Collins <rbtcollins@xxxxxx>
Distinguished Technologist
HP Cloud Services