Open Stack

On Thu, Mar 26, 2015 at 7:58 PM, Russell Bryant <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.


> > 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.
>
> ++
>
> Huge thank you to all those who have spent time doing proof of concept
work and helping to wrangle things1


> --
> Russell Bryant
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150326/6f72e267/attachment.html>