Open Stack

building a new cloud is not practical for real production environments.
even if you can afford it, how do you migrate data?

We have been doing upgrades for a while now, and came up with few basic
principles:
1) you don't have to upgrade all at the same time. do it component at the
time
2) stand up a new version along side of an existing one, test it and then
flip DNS

Take a look at presentation team did during Vancouver summit
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done

On Sun, Mar 6, 2016 at 5:41 PM, Kavit Munshi <kavit at aptira.com> wrote:

> 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 <robert at 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 <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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>


-- 
yuriy brodskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160309/7c5e5a56/attachment-0001.html>