Open Stack

On 01/09/2015 05:04 AM, Thierry Carrez wrote:
> Maru Newby wrote:
>>> On Jan 8, 2015, at 3:54 PM, Sean Dague <sean at dague.net> wrote:
>>>
>>> The crux of it comes from the fact that the operator voice (especially
>>> those folks with large nova-network deploys) wasn't represented there.
>>> Once we got back from the mid-cycle and brought it to the list, there
>>> was some very understandable push back on deprecating without a
>>> migration plan.
>>
>> I think it’s clear that a migration plan is required.  An automated migration, not so much.
> 
> The solution is not black or white.
> 
> Yes, operators would generally prefer an instant, automated, no-downtime
> "hot" migration that magically moves them to the new world order. Yes,
> developers would generally prefer to just document a general "cold"
> procedure that operators could follow to migrate, warning that their
> mileage may vary.
> 
> The trade-off solution we came up with last cycle is to have developers
> and operators converge on a clear procedure with reasonable/acceptable
> downtime, potentially assisted by new features and tools. It's really
> not a "us vs. them" thing. It's a collaborative effort where operators
> agree on what level of pain they can absorb and developers help to
> reduce that pain wherever reasonably possible.
> 
> This convergence effort is currently rebooted because it has stalled. We
> still need to agree on the reasonable trade-off procedure. We still need
> to investigate if there is any tool or simple feature we can add to
> Neutron or Nova to make some parts of that procedure easier and less
> painful.
> 
> So we are not bringing back the magic upgrade pony requirement on the
> table. We are just rebooting the effort to come to a reasonable solution
> for everyone.

If we were standing at a place with a detailed manual upgrade document
that explained how to do minimal VM downtime, that a few ops had gone
through and proved out, that would be one thing. And we could figure out
which parts made sense to put tooling around to make this easier for
everyone.

But we seem far from there.

My suggestion is to start with a detailed document, figure out that it
works, and build automation around that process.

	-Sean

-- 
Sean Dague
http://dague.net