<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>

<br>
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.<br>
</blockquote><div><br></div><div>There have been several discussions and ideas over time. I've tried to collect as many as I've had exposure to on the whiteboard here: <a href="https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade">https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade</a> </div>
<div><br></div><div>Generally speaking we've all agreed before that while zero downtime would be great, minimal downtime would be just fine. If it means a little API downtime and some packet loss while an instance is replugged (maybe doing a suspend while this happens would be safer) then it's still a big win. Having to snap, delete and redeploy is less desirable but if there's an automated process for that which can be controlled by the user (not the admin) then that may be ok too.</div>
<div><br></div><div>Best regards,</div><div><br></div><div>Jesse</div></div></div></div>