<div dir="ltr"><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><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">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>_______________________________________________<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>