Open Stack

On 04/25/2013 08:08 PM, Joshua Harlow wrote:
> Since I wanted to make sure everyone was aware of this, since some of
> you might have missed the summit session and I'd like discussions so we
> can land code in havana.
> 
> For those that missed the session & associated material.
> 
> - https://etherpad.openstack.org/the-future-of-orch (session details +
> discussion …)

So my take on all of this is:

The goals here are good.  Having better tracking of state through long
running opertions is A Good Thing, and we should continue to take steps
in that direction.

The trick with a large effort in an extremely active open source project
is how to approach it in an iterative manner so that the patches have a
chance of going in.

I believe that the specific operations that would benefit the most from
this type of improvement are migrate/live-migrate/resize/evacuate.
These operations are complex long running tasks.  Further, they involve
multiple compute nodes.  Right now the flow of control is passed around
and not tracked as well as it could be.  We should improve it, which
includes some of the ideas from this proposal (at some point down the path).

So, here is my specific proposal for a first set of tasks to complete in
Havana:

1) At the design summit, we spent a session discussing the state of
these code paths.  The *first* problem we have to solve with them is the
fact that they are quite separate code paths, when much of it can be and
should be combined.

This is a cleanup task, but a fairly complex one.  Combining these in
the areas where it makes sense will also aid us in getting effective
test coverage over these operations.  Right now we have poor coverage
here and they are at high risk for breaking over time.

Some summit discussion notes here:

https://etherpad.openstack.org/HavanaUnifyMigrateAndLiveMigrate

2) At the same time as #1, one thing that would be a helpful design
artifact is some diagrams that show the flow of how these operations
work today.  I spoke with Joshua Harlow about this and it sounded like
something he would be willing to work on.  I think many people would
benefit with having a diagram that explains these operations.

3) Take a look at shifting the flow of control from distributed among
services and compute nodes to a more centralized control.  This task is
taking the code, much as it exists today, but moving it around.
Specifically, this will probably mean having nova-conductor 'conduct'
these operations.


Havana blueprint (with a couple child blueprints) for reference:

https://blueprints.launchpad.net/nova/+spec/unified-migrations


I believe that all of those things will be a lot of work.  I will be
quite happy if we accomplish all of that in the Havana cycle.  I also
believe that all of these tasks are prerequisites to applying a workflow
library (or service) to these operations.  Once we have the code cleaned
up, moved so that it's more central, then we can look at applying a
workflow library as the next step.

Iterative, forward progress!  :-)

Thanks,

-- 
Russell Bryant