On 09/08/14 05:09, Russell Bryant wrote:
On 08/06/2014 01:41 PM, Jay Pipes wrote:
On 08/06/2014 01:40 AM, Tom Fifield wrote:
On 06/08/14 13:30, Robert Collins wrote:
On 6 August 2014 17:27, Tom Fifield <t...@openstack.org> wrote:
On 06/08/14 13:24, Robert Collins wrote:

What happened to your DB migrations then? :)


Sorry if I misunderstood, I thought we were talking about running VM
downtime here?

While DB migrations are running things like the nova metadata service
can/will misbehave - and user code within instances will be affected.
Thats arguably VM downtime.

OTOH you could define it more narrowly as 'VMs are not powered off' or
'VMs are not stalled for more than 2s without a time slice' etc etc -
my sense is that most users are going to be particularly concerned
about things for which they have to *do something* - e.g. VMs being
powered off or rebooted - but having no network for a short period
while vifs are replugged and the overlay network re-establishes itself
would be much less concerning.

I think you've got it there, Rob - nicely put :)

In many cases the users I've spoken to who are looking for a live path
out of nova-network on to neutron are actually completely OK with some
"API service" downtime (metadata service is an API service by their
definition). A little 'glitch' in the network is also OK for many of
them.

Contrast that with the original proposal in this thread ("snapshot VMs
in old nova-network deployment, store in Swift or something, then launch
VM from a snapshot in new Neutron deployment") - it is completely
unacceptable and is not considered a migration path for these users.

Who are these users? Can we speak with them? Would they be interested in
participating in the documentation and migration feature process?

Yes, I'd really like to see some participation in the development of a
solution if it's an important requirement.  Until then, it feels like a
case of an open question of "what do you want".  Of course the answer is
"a pony".


... and this is exactly why """...raising this concept only on a development mailing list is a bad idea

If anyone is serious about not providing a proper migration path for these users that need it, there is a need to be yelling this for probably a few of summits in a row and every OpenStack event we have in between, as well as the full gamut of periodic surveys, blogs, twitters, weibos, linkedins, facebooks etc,"""

So, get cracking :)


Regards,


Tom


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to