On Wed, Aug 06, 2014 at 01:40:28PM +0800, Tom Fifield wrote: <snip/> > >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. > > > Regards, > > > Tom
I've thought about this off and on since it was brought up at summit. I have some concerns about expectations. While I could probably rattle on, I'll stick to the two for now. - We need to be clear with expectations with connection resets and other odd connection behavior. There are some nice little gotchas for some applications when an IP address is moved depending on how connection is being used. Floating IPs could be interesting as well as nova-network and neutron differ quite a bit in how they are implemented. The ultimate effect on running applications will of course depend on whether or not they can handle things of that nature. Apps designed for failover, stale connections, etc, will probably fare better than those that are not. Apps designed for cattle vms probably will do okay too. I imagine pets will be higher risk and interestingly enough, they seem to be a more likely target use case. I suppose this falls under the category of "glitch", but the pessimist (realist?) in me is having a hard time that some deployments are going to run into problems... which is a nice segue into the next concern. - I wonder about uncommunicated expectations with migration rollback in case of the "all gone to hell, we need to put it back" situation. We have been talking about migrating a live VM from nova-network to neutron, but what about the way back? Are new VM boots going to be prevented until an all-clear is given to prevent orphans if nova-network needs to be put back in place? Or are we saying it is a "never look back" type of deal? Has this been discussed and all worked out and I just missed it? This concerns me a great deal because cannot imagine any of the admins I've ever worked with doing something without a failsafe backup to "known good" state whether the end up needing it or not. I'm not convinced that these have been thoroughly considered, nor are they addressable in the very near future. I also am *deeply* concerned that placing significant focus on this PRIOR to achieving parity with nova-network both in function and stability jeopardizes all. That is not to diminish the efforts of those that have already contributed heavily in this area. However, this work is all for nothing if we haven't covered the necessary gaps so that the users have something to migrate *to*. Cheers, Brent _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev