Open Stack

On 08/05/2014 09:34 AM, Mike Spreitzer wrote:
> Monty Taylor <mordred at inaugust.com> wrote on 08/05/2014 12:27:14 PM:
>
>> 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.rst
>
>>>
>>> ...
>>>
>>> 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!
>>>
>>> ...
>>
>> 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.
>
> I will go a little further.  My focus is on workloads that are composed of
> scaling groups (one strict way of saying "cattle not pets").  In this case
> I do not need to migrate individual Compute instances, just shut down
> obsolete ones and start shiny new ones.

To be complete - I feel the urge to communicate that I run a very large 
production infrastructure (that you all use) that is comprised of 
_several_ precious pets. I reject the notion that cloud is only for 
ephemeral things or that you can't do old-style workloads. It works great!

So, if I was a user of a cloud that told me I needed to do a downtime to 
migrate, it would be a bad user experience. Oh wait - it WAS a bad user 
experience when Rackspace migrated us from Rackspace Classic to 
Rackspace Nova. Guess what? We got over it - and thus far it's been the 
only time that's happened - so 4 years in to the OpenStack project, our 
control plane is still running on Rackspace.

Which is to say that there are people who will have pets and not cattle, 
and not having a magical seamless upgrade path from nova-network to 
neutron will annoy them. However, I think the cost to providing that 
path far outweighs the benefit in the face of other things on our plate.