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" <mord...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
