<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 class=""><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 class="h5">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 class="h5"><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">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>