Open Stack

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 <matt at 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 <alawson at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160303/00def4ef/attachment.html>