Open Stack

On 04/25/2013 04:01 PM, Joshua Harlow wrote:
> I just wanted to ensure that this doesn't get lost so am cc'ing others
> for more details.
> 
> I remember in either the mothballing session or the host migrate session
> that there was talk about how to do live migration and resizing in a way
> that does not involve shared ssh keys.
> 
> I'd like to start a wiki at least to catch the ideas that were talked
> about, since at y! its a big issue (we can't use live migration/resizing
> if we have to allow unlimited hypervisor<->hypervisor connectivity). I
> can go into the reasons as to why that is the case, if that’s useful but
> some of this was mentioned in one of those sessions.
> 
> I remember there being talk about possible solutions, something along
> the lines of a external entity (orchestration/conductor… whatever)
> creating a session key for said hypervisors, then allowing communication
> between those hypervisors to perform said operation for a limited period
> of time. That’s one approach, said orchestration/conductor could also
> open a secure tunnel and tell the hypervisors to use said channel (and
> then said orchestration/conductor thingy could close that channel
> automatically…) for communication.
> 
> This is a very interesting change, so more feedback is always welcome :-)

Yes, it is quite an important issue that we need to resolve.  You
roughly captured the ideas discussed.  The next step is that someone
needs to step up to document a design and implement it.

However, this is a bit of a hot area of the code right now.  One of the
things that I'm hoping will start early in the cycle is refactoring the
code paths for migrate/live-migrate/resize/evacuate.  Much of the
handling of all of these things can be shared in a single code path, but
that's not the case right now.  Since this will be rather invasive, it
needs to happen before other efforts in the same area, such as the one
you're mentioning here.

I think part of this refactoring will be pulling it up a layer to be
more managed by nova-conductor, as opposed to compute nodes managing
each other.  Once we have this refactoring in place, fixing this
security issue will become much easier to do.

-- 
Russell Bryant