Open Stack

I think depending on use-case it can be accomplished.

The steps we have been thinking at Y!

1. Take offline APIs & nova-compute (so new/existing VMs can't be
scheduled/modified) -- existing running VMs will not be affected.
2. Save/dump nova database.
3. Translate nova database entries into corresponding neutron database
entries.
4. Remove/adjust the *right* entries of the nova database.
5. Startup neutron+agents with database that it believes it was running
with the whole time.
6. Restart nova-api & nova-compute (it will now never know that it was
previously using nova-network).
7. Profit!

Depending on the use-case and how complex your impl. is something like the
above should work. Of course the devil is in the details ;)

On 1/29/14, 11:50 AM, "Tim Bell" <Tim.Bell at cern.ch> wrote:

>
>I'm not seeing a path to migrate 1,000s of production VMs from nova
>network to Neutron.
>
>Can someone describe how this can be done without downtime for the VMs ?
>
>Can we build an approach for the cases below in a single OpenStack
>production cloud:
>
>1. Existing VMs to carry on running without downtime (and no new features)
>2. Existing VMs to choose a window for reconfiguration for Neutron (to
>get the new function)
>3. New VMs to take advantage of Neutron features such as LBaaS
>- 
>Tim
>
>> -----Original Message-----
>> From: Russell Bryant [mailto:rbryant at redhat.com]
>> Sent: 29 January 2014 19:04
>> To: Daniel P. Berrange
>> Cc: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Nova][Neutron] nova-network in Icehouse
>>and beyond
>> 
>> On 01/29/2014 12:45 PM, Daniel P. Berrange wrote:
>> > I was thinking of an upgrade path more akin to what users got when we
>> > removed the nova volume driver, in favour of cinder.
>> >
>> >   https://wiki.openstack.org/wiki/MigrateToCinder
>> >
>> > ie no guest visible downtime / interuption of service, nor running of
>> > multiple Nova instances in parallel.
>> 
>> Yeah, I'd love to see something like that.  I would really like to see
>>more effort in this area.  I honestly haven't been thinking about it
>> much in a while personally, because the rest of the "make it work" gaps
>>have still been a work in progress.
>> 
>> There's a bit of a bigger set of questions here, too ...
>> 
>> Should nova-network *ever* go away?  Or will there always just be a
>>choice between the basic/legacy nova-network option, and the
>> new fancy SDN-enabling Neutron option?  Is the Neutron team's time
>>better spent on OpenDaylight integration than the existing
>> open source plugins?
>> 
>> Depending on the answers to those questions, the non-visible
>>no-downtime migration path may be a less important issue.
>> 
>> --
>> Russell Bryant
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev