<div dir="ltr"><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">building a new cloud is not practical for real production environments. even if you can afford it, how do you migrate data?</div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><br></div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">We have been doing upgrades for a while now, and came up with few basic principles:</div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">1) you don't have to upgrade all at the same time. do it component at the time</div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">2) stand up a new version along side of an existing one, test it and then flip DNS</div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><br></div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">Take a look at presentation team did during Vancouver summit </div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><a href="https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done">https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 5:41 PM, Kavit Munshi <span dir="ltr"><<a href="mailto:kavit@aptira.com" target="_blank">kavit@aptira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="tahoma, sans-serif">Shameless plug :)</font></div><div class="gmail_default"><font face="tahoma, sans-serif"><br></font></div><div class="gmail_default"><font face="tahoma, sans-serif">For people currently running a distro but wanting to run CI, please checkout StackBuffet (<a href="https://aptira.com/stackbuffet/" target="_blank">https://aptira.com/stackbuffet/</a>) </font></div><div class="gmail_default"><font face="tahoma, sans-serif"><br></font></div><div class="gmail_default"><font face="tahoma, sans-serif">Currently under beta, looking for customers with real use cases to help us test</font></div><div class="gmail_default"><font face="tahoma, sans-serif"><br></font></div><div class="gmail_default"><font face="tahoma, sans-serif">regards,</font></div><div class="gmail_default"><font face="tahoma, sans-serif"><br></font></div><div class="gmail_default"><font face="tahoma, sans-serif">Kavit</font></div></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div></div><div><p style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="tahoma, sans-serif"><span style="line-height:14.9499998092651px;white-space:pre-wrap"><b>Kavit Munshi</b></span></font></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="tahoma, sans-serif"><span style="line-height:14.9499998092651px;white-space:pre-wrap"><b>Aptira - Asia Pacific’s leading provider of OpenStack</b></span></font></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="tahoma, sans-serif"><span style="line-height:14.9499998092651px;white-space:pre-wrap">Direct/mobile: +91 971 292 9850</span></font></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="tahoma, sans-serif"><span style="line-height:14.9499998092651px;white-space:pre-wrap">General enquiries: <a href="tel:%2B61%202%208030%202333" value="+61280302333" target="_blank">+61 2 8030 2333</a></span></font></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><font color="#000000" face="tahoma, sans-serif"><span style="line-height:14.9499998092651px;white-space:pre-wrap">Australia toll free: 1800 APTIRA</span></font></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:14.9499998092651px;white-space:pre-wrap;color:rgb(0,0,0);font-family:tahoma,sans-serif">Website </span><a href="https://aptira.com/" style="line-height:14.9499998092651px;white-space:pre-wrap;font-family:tahoma,sans-serif;color:rgb(17,85,204)" target="_blank">aptira.com</a><br></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:14.9499998092651px;white-space:pre-wrap;color:rgb(0,0,0);font-family:tahoma,sans-serif">Twitter </span><a href="https://twitter.com/aptira" style="line-height:14.9499998092651px;white-space:pre-wrap;font-family:tahoma,sans-serif;color:rgb(17,85,204)" target="_blank">@aptira</a><br></p></div><div><font color="#000000" face="tahoma, sans-serif"><br></font></div></div></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On 4 March 2016 at 04:34, Robert Starmer <span dir="ltr"><<a href="mailto:robert@kumul.us" target="_blank">robert@kumul.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have to agree, unless you start with CI/CD as your deployment model, you're going to be doing full upgrades. And be aware that at least one package model will overwrite your carefully crafted config files if you choose the wrong option. Having tried an upgrade to a system in the middle of an upstream update, I can say that this is potentially a painful few hours tracking down what's changed, and where my config files got tweaked (yes, I'm looking at you Keystone...). Fun for all ages.<div><br></div><div>And while I agree that it is difficult to stand up two clouds, you can stand up a smaller new cloud, migrate those workloads that are cloud native (just heard your cattle that-a-way), and as the load increases, migrate the hardware from one cloud to another. It's almost a square dance, and it's never perfect, but it is doable...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 2:58 PM, Silence Dogood <span dir="ltr"><<a href="mailto:matt@nycresistor.com" target="_blank">matt@nycresistor.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><ul style="font-size:12.8px"><li style="margin-left:15px">In-place Full Release upgrades (upgrade an entire cloud from Icehouse to Kilo for instance)</li></ul></span><div><span style="font-size:12.8px">This tends to be the most likely scenario with CI/CD being almost impossible for anyone using supported openstack components ( such as SDN / NAS / other hardware integration pieces ).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That's not to say people don't almost always test on a test environment ( other cloud ) first.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Mar 2, 2016 at 4:34 PM, Adam Lawson <span dir="ltr"><<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hey all,<div><br></div><div>So I've been discussing cloud design with the team and of course the topic comes up about how upgrades will be handled.</div><div><br></div><div>Handling OpenStack code updates generally consists of three paths in my experience:</div><div><ul><li>CI/CD (continuous incremental upgrades)<br></li><li>In-place Full Release upgrades (upgrade an entire cloud from Icehouse to Kilo for instance)<br></li><li>Migrating old cloud to new cloud</li></ul></div><div>Is there a cloud maintenance strategy I'm missing that doesn't fall into the categories above? How are the rest of you adopting your cloud upgrade strategies and how has cloud size impacted whatever strategy you ultimately selected? Migrating workloads from an Icehouse cloud with 1000 nodes to a Liberty cloud with similar capacity isn't always a realistic option due to cost, upgrading a cloud in place is super-risky and CI/CD takes a lot of development and testing overhead.<br></div><div><br></div><div>For CI/CD strategies, I'm also curious how the rest of you are handling disruptive tasks (for example replacing a vRouter with a newer version, updating the SQL schema etc etc)? Just looking to learn from everyone's experiences to hopefully keep my own thinking on where it needs to be.</div><div><br></div><div>Thanks!!!</div><div><br></div><div>//adam<br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial"><br></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: <a href="tel:%2B1%20302-387-4660" value="+13023874660" target="_blank">+1 302-387-4660</a></div></font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">Direct: <a href="tel:%2B1%20916-246-2072" value="+19162462072" target="_blank">+1 916-246-2072</a></div></font></font></div></font></div></div></div></div></div></div>
</div></div>
<br></div></div>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font face="'trebuchet ms', sans-serif">yuriy brodskiy</font><br style="font-family:trebuchet ms,sans-serif"></div></div>
</div>