Open Stack

On 03/26/2015 08:58 PM, Russell Bryant wrote:
> 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.
I heartily agree.

Here is my problem. I am getting the feeling from the big tent
discussions (now this could be my fault since I don't know as it is in
the proposal or just the "stuff people are making up about it") that we
are allowing more than one networking project in OpenStack. I have been
disappointed with that impression but that has been the impression I
have gotten.

I'm glad to hear you have a different perspective on this, Russell, and
would just like to clarify this point.

Are we saying that OpenStack has one networking option?

Thanks,
Anita.
> 
>> 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.
> 
> ++
>