<div dir="ltr"><div>Hi,</div><div><br></div>I'd like to encourage everybody interested to take a look and leave comments on the Neutron migration spec here: <div><a href="https://review.openstack.org/#/c/101921">https://review.openstack.org/#/c/101921</a></div>
<div><br><div>The design currently includes both "cold" and "live" approaches, supports host-by-host migration (as opposite to <span style="font-family:arial,sans-serif;font-size:13.333333969116211px">big bang</span>) </div>
<div>and doesn't require to freeze the whole deployment during upgrade.</div></div><div><br></div><div>I've also started prototyping the above spec:</div><div><a href="https://review.openstack.org/#/c/111755">https://review.openstack.org/#/c/111755</a> -<b> </b>Neutron migration: synchronize IP (de)allocations with Nova-net<br>
</div><a href="https://review.openstack.org/#/c/115635">https://review.openstack.org/#/c/115635</a> - Neutron migration as part of cold migration<div><span style="color:rgb(0,0,0);font-size:9pt;font-weight:bold"><br></span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 1:59 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> From: Michael Still [mailto:<a href="mailto:mikal@stillhq.com">mikal@stillhq.com</a>]<br>
> Sent: 25 August 2014 23:38<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds<br>
<div class=""><br>
...<br>
<br>
> Mark McClain and I discussed a possible plan for nova-network to neutron upgrades at the Ops Meetup today, and it seemed generally acceptable. It defines a "cold migration" as<br>
> freezing the ability to create or destroy instances during the upgrade, and then requiring a short network outage for each instance in the cell.<br>
> This is why I'm trying to understand the "no downtime" use case better. Is it literally no downtime, ever? Or is it a more simple "no simultaneous downtime for instances"?<br>
> Michael<br>
<br>
</div>The simultaneous downtime across the cloud is the one we really need to avoid. Short network outages (depending on how you define short) can be handled along with blocking API operations for short periods.<br>
<br>
The other item was how to stage the upgrade.. with a cloud of a significant size and some concerns about scalability, we would like to be able to do the migration as a set of steps rather than a big bang. During the gap between the steps, we'd like to open the APIs for usage, such as new VMs get created on Neutron hypervisors. Would that be a possibility ?<br>

<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>