On 08/05/2014 09:34 AM, Mike Spreitzer wrote:
Monty Taylor <mord...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
