Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160307/1ae0fbf0/attachment.html>