Open Stack

On Fri, Mar 27, 2015 at 09:31:39AM +1100, 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.
> 
> 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.

As Russell mentioned in an earlier response on this thread, the fact is
that most migrations from nova-net to Neutron would require custom work
to make it happen. Adding documentation on how to do migration from
nova-net to Neutron is a grand idea, but I suspect it will ultimately
fall short of the needs of the (very few) operators that would attempt
such a thing (as opposed to a cold migration from older nova-net zones
to newer greenfield Neutron zones).

> 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. 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

Actually, IMO, the end goal should be to provide our end users with the
most stable, simple to deploy and operate, and scalable network as a
service product. The goal shouldn't be the separation or deletion of the
nova-network code -- just as is true that the goal of the Gantt project
should not be the split of the nova-scheduler itself, but rather to
provide the most stable, intuitive and easy-to-use placement engine for
OpenStack end users.

>, 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?

As Sean mentioned (I think), if Neutron was attractive to nova-network
deployers as an alternative handler of cloud network servicing, then
there would be more value in spending time on the nova-network to
Neutron migration.

But, there's the rub. Neutron *isn't* attractive to this set of people
because:

a) It doesn't provide for automatic (sub)net allocation for a user or
tenant in the same way that nova-network just Gets This Done for a user
that wants to launch an instance. As I think Kevin Fox mentioned, a
cloud admin should be able to easily set up a bunch of networks usable
by tenants, and Nova should be able to ask Neutron to just do the
needful and wire up a subnet for use by the instance without the user
needing to create a subnet, a router object, or wiring up the
connectivity themselves. I complained about this very problem (of not
having automated subnet and IP assignments) nearly *two years ago*:

http://lists.openstack.org/pipermail/openstack-dev/2013-July/011981.html

and was told by Neutron core team members that they weren't really
interested in changing Neutron to be more like Nova's network
auto-service behaviours.

b) It is way more complicated to deploy Neutron than nova-network (even
nova-network in multihost mode). While the myriad vendor plugins for L2
and L3 are nice flexibility, they add much complexity to the deployment
of Neutron. Just ask Thomas Goirand, who is currently working on
packaging the Neutron vendor mechanism drivers for Debian, about that
complexity.

c) There's been no demonstration that data plane performance of
nova-network with linux bridging can be beaten by the open source
Neutron SDN solutions. Not having any reliable and transparent
benchmarking that compares the huge matrix of network topologies,
overlay providers, and data plane options is a major reason for the lack
of uptake of Neutron by all but the bravest greenfield deployments.

> 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.

Please, let's not split out nova-network. Let's instead focus on
improving Neutron in the areas where parity with nova-network is lacking
and making it as easily deployable and stable as nova-network.

Best,
-jay

> 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.
> 
> 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.
> 
> I'd appreciate other's thoughts on these issues.
> 
> Michael
> 
> 
> 1: http://specs.openstack.org/openstack/neutron-specs/specs/kilo/migration-from-nova-net.html#impact-limitations
> 
> 
> -- 
> Rackspace Australia
> 
> __________________________________________________________________________
> 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