On 03/26/2015 08:58 PM, Russell Bryant 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. I heartily agree.
Here is my problem. I am getting the feeling from the big tent discussions (now this could be my fault since I don't know as it is in the proposal or just the "stuff people are making up about it") that we are allowing more than one networking project in OpenStack. I have been disappointed with that impression but that has been the impression I have gotten. I'm glad to hear you have a different perspective on this, Russell, and would just like to clarify this point. Are we saying that OpenStack has one networking option? Thanks, Anita. > >> 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. > >> 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. > > ++ > __________________________________________________________________________ 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
