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.
> 
> 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.
> 
> 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, 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?
> 
> 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.
> 
> 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
> 
> 
Thank you, Michael, for this post.

It is clear that we need some additional discussion and agreement here,
and I welcome the discussion.

It is disheartening to try to create an implementation that won't
achieve the goal.

I too would like to thank everyone who has worked hard to try to create
a migration path with the understanding we had been operating with, my
thanks to each of you.

I have placed the weekly nova-net to neutron migration meeting on
hold[0], pending the outcome of this or other discussions and some
additional direction.

Thank you to all participating,
Anita.

[0] https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration