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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev