Open Stack

On 03/26/2015 06:31 PM, Michael Still wrote:
> Hi,
> 
> I thought it would be a good idea to send out a status update for the
> migration from nova-network to Neutron, as there hasn't been as much
> progress as we'd hoped for in Kilo. There are a few issues which have
> been slowing progress down.

Thanks for writing up the status!

> First off, creating an all encompassing turn key upgrade is probably
> not possible. This was also never a goal of this effort -- to quote
> the spec for this work, "Consequently, the process described here is
> not a “one size fits all” automated push-button tool but a series of
> steps that should be obvious to automate and customise to meet local
> needs" [1]. The variety of deployment and configuration options
> available makes a turn key migration very hard to write, and possibly
> impossible to test. We therefore have opted for writing "migration
> tools", which allow operators to plug components together in the way
> that makes sense for their deployment and then migrate using those.

Yes, I'm quite convinced that it will end up being a fairly custom
effort for virtually all deployments complex enough where just starting
over or cold migration isn't an option.

> However, talking to operators at the Ops Summit, is has become clear
> that some operators simply aren't interested in moving to Neutron --
> largely because they either aren't interested in tenant networks, or
> have corporate network environments that make deploying Neutron very
> hard. 

I totally get point #1: "nova-network has less features, but I don't
need the rest, and nova-network is rock solid for me."

I'm curious about the second point about Neutron being more difficult to
deploy than nova-network.  That's interesting because it actually seems
like Neutron is more flexible when it comes to integration with existing
networks.  Do you know any more details?  If not, perhaps those with
that concern could fill in with some detail here?

> So, even if we provide migration tools, it is still likely that
> we will end up with loyal nova-network users who aren't interested in
> moving. From the Nova perspective, the end goal of all of this effort
> is to delete the nova-network code, and if we can't do that because
> some people simply don't want to move, then what is gained by putting
> a lot of effort into migration tooling?

To me it comes down to the reasons people don't want to move.  I'd like
to dig into exactly why people don't want to use Neutron.  If there are
legitimate reasons why nova-network will work better, then Neutron has
not met parity and we're certainly not ready to deprecate nova-network.

I still think getting down to a single networking project should be the
end goal.  The confusion around networking choices has been detrimental
to OpenStack.

> Therefore, there is some talk about spinning nova-network out into its
> own project where it could continue to live on and be better
> maintained than the current Nova team is able to do. However, this is
> a relatively new idea and we haven't had a chance to determine how
> feasible it is given where we are in the release cycle. I assume that
> if we did this, we would need to find a core team passionate about
> maintaining nova-network, and we would still need to provide some
> migration tooling for operators who are keen to move to Neutron.
> However, that migration tooling would be less critical than it is now.

>From a purely technical perspective, it seems like quite a bit of work.
 It reminds me of "we'll just split the scheduler out", and we see how
long that's taking in practice.  I really think all of that effort is
better spent just improving Neutron.

>From a community perspective, I'm not thrilled about long term
fragmentation for such a fundamental piece of our stack.  So, I'd really
like to dig into the current state of gaps between Neutron and
nova-network.  If there were no real gaps, there would be no sensible
argument to keep the 2nd option.

> Unfortunately, this has all come to a head at a time when the Nova
> team is heads down getting the Kilo release out the door. We simply
> don't have the time at the moment to properly consider these issues.
> So, I'd like to ask for us to put a pause on this current work until
> we have Kilo done. These issues are complicated and important, so I
> feel we shouldn't rush them at a time we are distracted.

Makes sense.  It seems clear this has now pushed back another release
(at least).

> Finally, I want to reinforce that the position we currently find
> ourselves in isn't because of a lack of effort. Oleg, Angus and Anita
> have all worked very hard on this problem during Kilo, and it is
> frustrating that we haven't managed to find a magic bullet to solve
> all of these problems. I want to personally thank each of them for
> their efforts this cycle on this relatively thankless task.

++

-- 
Russell Bryant