Open Stack

Jay,

I do agree with you on the focus areas. I believe Neutron should focus on
the nova-parity (DVR) and DB migrations more than ever, instead of
increasing the priority to new API such as the GBP. Actually, yesterday
Neutron IRC showed the need of having a more focused work instead of
picking in to many ³N² different areas.

The part that I disagree is with the focus on the nova-network -> Neutron
migration. I feel this activity is under control and even that it will not
deliver the ³no-downtime² expect ion, it will offer an alternative to
migration instances for those operators that could be interested.

Now, if Metacloud has a process that will work, please share it and let¹s
document it. The more the merrier, it will be up to the operators to chose
the best approach for their own clouds.

Edgar

On 8/5/14, 9:27 AM, "Monty Taylor" <mordred at inaugust.com> wrote:

>On 08/05/2014 09:18 AM, Jay Pipes wrote:
>> Hello stackers, TC, Neutron contributors,
>>
>> At the Nova mid-cycle meetup last week in Oregon, during the discussion
>> about the future of nova-network, the topic of nova-network -> Neutron
>> migration came up.
>>
>> For some reason, I had been clueless about the details of one of the
>> items in the gap analysis the TC had requested [1]. Namely, the 5th
>> item, about nova-network -> Neutron migration, which is detailed in the
>> following specification:
>>
>> 
>>https://review.openstack.org/#/c/101921/12/specs/juno/neutron-migration.r
>>st
>>
>> The above specification outlines a plan to allow migration of *running*
>> instances from an OpenStack deployment using nova-network (both with and
>> without multi-host mode) to an OpenStack deployment using Neutron, with
>> little to no downtime using live migration techniques and an array of
>> post-vm-migrate strategies to wire up the new VIFs to the Neutron ports.
>>
>> I personally believe that this requirement to support a live migration
>> with no downtime of running instances between a nova-network and a
>> Neutron deployment *is neither realistic, nor worth the extensive time
>> and technical debt needed to make this happen*.
>>
>> I suggest that it would be better to instead provide good instructions
>> for doing cold migration (snapshot VMs in old nova-network deployment,
>> store in Swift or something, then launch VM from a snapshot in new
>> Neutron deployment) -- which should cover the majority of deployments --
>> and then write some instructions for what to look out for when doing a
>> custom migration for environments that simply cannot afford any downtime
>> and *really* want to migrate to Neutron. For these deployments, it's
>> almost guaranteed that they will need to mangle their existing databases
>> and do manual data migration anyway -- like RAX did when moving from
>> nova-network to Neutron. The variables are too many to list here, and
>> the number of deployments actually *needing* this work seems to me to be
>> very limited. Someone suggested Metacloud *might* be the only deployment
>> that might meet the needs for a live nova-network -> Neutron migration.
>> Metacloud folks, please do respond here!
>>
>> In short, I don't think the live migration requirement for nova-network
>> to Neutron is either realistic or valuable, and suggest relaxing it to
>> be good instructions for cold migration of instances from an older
>> deployment to a newer deployment. There are other more valuable things
>> that Neutron contributors could focus on, IMO -- such as the DVR
>> functionality that brings parity to Neutron with nova-network's
>> multi-host mode.
>>
>> Thoughts?
>
>I agree 100%. Although I understand the I think it's an unreasonably
>high burden in an area where there are many many other real pressing
>issues that need to be solved.
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev