Shameless plug :) For people currently running a distro but wanting to run CI, please checkout StackBuffet (https://aptira.com/stackbuffet/)
Currently under beta, looking for customers with real use cases to help us test regards, Kavit *Kavit Munshi* *Aptira - Asia Pacific’s leading provider of OpenStack* Direct/mobile: +91 971 292 9850 General enquiries: +61 2 8030 2333 Australia toll free: 1800 APTIRA Website aptira.com Twitter @aptira <https://twitter.com/aptira> On 4 March 2016 at 04:34, Robert Starmer <rob...@kumul.us> wrote: > 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. > > 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... > > On Wed, Mar 2, 2016 at 2:58 PM, Silence Dogood <m...@nycresistor.com> > wrote: > >> >> - In-place Full Release upgrades (upgrade an entire cloud from >> Icehouse to Kilo for instance) >> >> 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 ). >> >> That's not to say people don't almost always test on a test environment ( >> other cloud ) first. >> >> On Wed, Mar 2, 2016 at 4:34 PM, Adam Lawson <alaw...@aqorn.com> wrote: >> >>> Hey all, >>> >>> So I've been discussing cloud design with the team and of course the >>> topic comes up about how upgrades will be handled. >>> >>> Handling OpenStack code updates generally consists of three paths in my >>> experience: >>> >>> - CI/CD (continuous incremental upgrades) >>> - In-place Full Release upgrades (upgrade an entire cloud from >>> Icehouse to Kilo for instance) >>> - Migrating old cloud to new cloud >>> >>> 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. >>> >>> 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. >>> >>> Thanks!!! >>> >>> //adam >>> >>> *Adam Lawson* >>> >>> AQORN, Inc. >>> 427 North Tatnall Street >>> Ste. 58461 >>> Wilmington, Delaware 19801-2230 >>> Toll-free: (844) 4-AQORN-NOW ext. 101 >>> International: +1 302-387-4660 >>> Direct: +1 916-246-2072 >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
