Open Stack

Kyle Mestery wrote:
> On Thu, Mar 26, 2015 at 7:58 PM, Russell Bryant <rbryant at redhat.com
> <mailto:rbryant at redhat.com>> 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.
> 
>     > 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.
> 
> I agree with Russell here. After talking to a few folks, my sense is
> there is still a misunderstanding between people running nova-network
> and those developing Neutron. I realize not everyone wants tenant
> networks, and I think we can look at the use case for that and see how
> to map it to what Neutron has, and fill in any missing gaps. There are
> some discussions started already to see how we can fill those gaps.

Part of it is corner (or simplified) use cases not being optimally
served by Neutron, and I think Neutron could more aggressively address
those. But the other part is ignorance and convenience: that Neutron
thing is a scary beast, last time I looked into it I couldn't make sense
of it, and nova-network just works for me.

That is why during the Ops Summit we discussed coming up with a
migration guide that would explain the various ways you can use Neutron
to cover nova-network use cases, demystify a few dark areas, and outline
the step-by-step manual process you can go through to migrate from one
to the other.

We found a dev/ops volunteer for writing that migration guide but he was
unfortunately not allowed to spend time on this. I heard we have new
volunteers, but I'll let them announce what their plans are, rather than
put words in their mouth.

This migration guide can happen even if we follow the nova-net spinout
plan (for the few who want to migrate to Neutron), so this is a
complementary solution rather than an alternative. Personally I doubt
there would suddenly be enough people interested in nova-net development
to successfully spin it out and maintain it. I also agree with Russell
that long-term fragmentation at this layer of the stack is generally not
desirable.

-- 
Thierry Carrez (ttx)