Why isn’t nova-network a Neutron plugin?

Some time ago we started a virtual round-table looking at one particular networking issue, and now it’s high time to reveal the first results. What we wanted to know is why we had to have two separate networking camps, one for nova-network and one for neutron. It’s not that we love nova-network so much, it’s just that we do care about users who have already implemented it, and for whom transitioning to Neutron isn’t a trivial matter.

So that was our starting point:  “Why isn’t nova-network a Neutron plugin?”

Nick Chase, Editor-in-Chief @ OpenStack:Now

The question is not, “How can you use nova-network as part of neutron?”  The answer to that is “You can’t, because there is not currently a way to do that.”  We all accept that.  The question is, “WHY has nova-network not been made into a plugin for neutron?”  If it were, then any scripts, management systems, applications, and so on that require the nova-network API would still work, even though the cloud itself is running on Neutron.  

It’s given that the cloud would need to be redeployed to change over from nova-network to Neutron; that’s not the question.  The situation we’re looking at is the following: pretend, for a moment, that someone implements nova-network as a plugin for Neutron, and it goes into the Liberty release.  I’m an operator who has a Kilo cloud using nova-network, and all of my apps use the nova-network API.  I upgrade my cloud to Liberty with Neutron and the nova-network plugin (or I install a brand new cloud using Liberty with Neutron and the nova-network plugin).  At this point all of my apps, scripts or whatever should still work, because the nova-network API will still be available, so the change should be transparent to me.  So the question is, if that’s true, then it’s a pretty clear migration path from nova-network to neutron.  Why hasn’t it been done?

The conversation started at the OpenStack Summit in Vancouver this past May, when Nick spoke with Edgar Magaña.

Edgar Magaña, Neutron contributor and Cloud Operations Architect @ Workday

EM: Yeah, that’s a great point. If I had the opportunity to re-do everything, go back in time and start over with Neutron, I would have started with replacing nova-network right away.  We could actually move most of the core in nova-network and put it in Neutron clothing, and to provide the same functionality. With that, we would not have had the problem of providing migration from nova-network to Neutron, because it would be already embedded. So I would’ve focused the project on replacing, in the first release, in the first cycle, nova-network, and then start adding all the good functionality that we added in Neutron later on. Because, at that time, you know what happened, there was so much functionality nonexistent even in nova-network.  

Nick Chase: Right, so with everybody saying, “Oh, we need to migrate, we need to migrate,” could nova-network be made into a plugin for Neutron?

EM: Of course.  We’re problem solving engineers.  We can solve all those kinds of problems when there is a good approach and architectural thinking. But I strongly believe that we can move some of the nova-network code into Neutron and just get rid of the nova-network complexity or overlapping functionality with it.  

Of course a lot of people have different opinions on that.  Probably a good approach would be to write the code, make it a proposal, create templates and everything and get some feedback from the community.

NC: Is there any reason not to do that?

EM: I don’t see a lot of people really interested in that approach.  I think they just want to have a nice migration path.  We don’t want to move code around—that’s bad practice, right?  What is the point of just moving from nova-network to Neutron?  But, on the other hand, if you don’t solve the problem, you will end up having the same discussion over and over.  “When are we gonna duplicate nova-network?” We’ve been saying that probably almost two years, discussing the same thing over and over.

NC: It seems to me, though, that if you made nova-network a plugin for Neutron, that would be your nice migration path from nova-network to Neutron.

EM: That’s my opinion.  That’s probably something that we need to digest a little bit better, how that would be possible, what we would need to do, but from the design of the plugin, from the design of both, I don’t see why that couldn’t happen.

That’s not to say that everyone agrees.

Sergey Vasilenko, Senior Deployment Engineer @ Mirantis

SV: The major unavoidable difference between Neutron and nova-network is nova-network, being part of Nova, does not require an additional API to manage networking. If nova-network becomes part of Neutron (as a plugin) — the API for network configuration will not be provided by Nova. The end user would use the Neutron API for networking configuration. I do not see a principal difference between migrating existing clouds from nova-network to Neutron and migration from nova-network to Neutron with a nova-network plugin. Also, the solution of “Neutron with nova-network plugin” will lead to an increase in the amount of network configuration cases, which duplicate each other.

NC: The general usage scenario is basically to make it possible to remove nova-network from Nova once and for all, and have everyone on Neutron.  The idea is that by making it a plugin of Neutron, users who currently use nova-network will not have to change how they interact with the system.  Or am I missing something?

SV: There are two ways to remove support for nova-network from Nova:

  • remove the network part of the code and leave an code for translating Nova API calls to Neutron API calls
  • remove all nova-network code (including the network API)

For the first way we do nothing. This way, if Neutron is enabled, nova-network API  calls will be translated to Neutron, and will translate in the future.

For the second way, a plugin for Neutron can’t fix things. No plugin for Neutron has the ability to add network API calls to Nova. A plugin for Neutron can extend the API only in Neutron.

However, if all you’re trying to do is make sure that apps, scripts, and so on created for nova-network continue working in Neutron, there’s another option.

Grigorii Antsiferov, Operation Engineer @ Mirantis

You can’t make nova-network into a plugin for Neutron, but it is possible to create Neutron configurations that behave like nova-network, and will work with existing network equipment configurations. They just won’t have SDN features. Since nova-network usage scenarios are pretty simple, it could be replaced with some predefined configuration patterns (such as FlatDHCP). Furthermore, to help customers with seamless transition to Neutron, we could implement an adaptor that emulates the nova-network CLI and API interfaces as closely as possible. I’m not sure if it’s worth the cost, however.

Then again, Ken Hui has another idea. If openstackers wants to move to Neutron that’s fine. Let them create a Neutron-like plugin for nova-network!  

Ken Hui, Director of Technical Marketing @ Platform9

Do we really need Neutron? How many of our customers really need the all functionality of the Neutron? Seventy percent of deployments are working with nova-network. But if don’t want to stay with nova-network, why not just to create something Neutron like as plugin for nova-network? Something around 80% of deployments have less than a thousand IPs across all VMs, not thousands subnets. So do they ever have an issue for more than 4 thousand subnets? Probably not.

Neutron is so complex. Probably a Neutron-like plugin for nova-network might be more relevant for their needs. I don’t know the technical requirement for this, but the idea seems useful for the majority of deployments.      

Of course, the ultimate direction has already been decided: nova-network will (eventually) be deprecated and removed. Let’s talk to a Neutron insider…

Mark McClain, Chief Technical Officer @ Akanda Inc, a member of the OpenStack Technical Committee and a core reviewer for Neutron

We actually did take a look at how we could integrate nova-network, and could we proxy Neutron back on nova-network.  One of the interesting things I think gets lost a little bit is that the underlying data models between how nova-network represents the state of the network, and how Neutron represents the state of the network, don’t mesh cleanly.  Neither is a superset of the other.  So when you do the translation it’s typically pretty lossy, but we did take a look at whether we could do that.  So that’s one of the challenges.  

The Neutron project, if you take a look at the history, it’s somewhat of a different experience than putting on the TC hat.  This is why when Cinder was spun out, or other products have been spun out on Nova, they took the existing working code base, formed a separate team, then spun out from there.  Then that way at least the evolution provided an immediate migration path.  Neutron’s history is slightly different, in which a new project was spawned to replace nova-network, but it started with a different code base, so the underlying models were different.  

In talking with some of the operators we did come up with a few ways that we could proxy it, but some of them run into scaling issues, or stability issues.  

So technically that’s been kind of interesting, but software’s always typically a solvable problem.  You put enough hours in it, you can make software do almost anything you want.  

But one of the more interesting things, having the background conversations of the Neutron network over the last year, the Operator Summit in March, as well as the Operator Session [during the OpenStack Summit in Vancover], what’s slowly been coming to bubbling up is people realizing that part of the nova-network to Neutron migration issue has been about documentation. It’s really about explaining what’s different about Neutron, because there’s a perception that Neutron doesn’t support many common cases in a network when in fact it does easily and simply.  

So that was a nice outcome of one of the sessions the other day, was we started working through the list of, hey, we don’t like this particular thing. Sean [Collins] did a good job of driving that session, and we get halfway through the list, and everybody’s like, wait, there were some real problems to fix, technical problems, but some of it was we can do a better job of explaining how Neutron works in comparison to nova-networking.  

Then there are some of the other gaps. For example, Jay Pipes was working on how we could simplify how network creation works, because Neutron does have a few more steps, because currently the Neutron API is basically like taking Lego bricks, and nova-network gives you a whole Lego house when you ask for a network.  So we’re taking a look at how we as a Neutron community can do that. One of the issues that’s bothered me at the TC level is that when you have dual networking APIs, it’s confusing within the community. You have operators that have for historical reasons used nova-network, which is great.  You have operators that deploy Neutron, but then you have operators that are in between getting mixed messages of which should I deploy on? Which one should I choose for new deployments?  

So I think really tightening up where we as a community are going, and what the direction is going to be, is how we can best serve the members of our community, because the migration is important.  We can’t leave behind people who have been very supportive of the Neutron and of the OpenStack community.

So we’ve got to make sure we have a rock solid migration that provides a path forward.  In some cases it will be somewhat smooth, and in some cases there’s still some technical work to be done, but the exciting thing is that the community is working on it.  They’re focused on talking about the “how” – it’s a collaboration between the technical leaders and the users and deployers, making sure we’re solving these problems.

Sometimes community consensus takes a while.  Because the two models don’t render well on each other, it means undertaking some education, and in the community process this has to work.  Some people get impatient when the community process goes slower than they would like, but at the end of the day, community is hard.  It takes some investment.  It takes time.  It takes effort.  

So I hope that we can make some definable progress in Liberty. Maybe we’ll get lucky and get all the way through, but I get the feeling there will still be some work to do during the end cycle, because some of the technical challenges are going to require a bit more work.  But I do know that large-scale operators are testing even the draft versions of nova-network to Neutron migration at a significant scale.

As you can see, it’s an issue with multiple positions. What’s your opinion? Should nova-network be incorporated into neutron? Should it be the other way around? Or is there some other solution nobody’s mentioned yet? Let us know in the comments below.

Subscribe to Our Newsletter

Latest Tweets

Suggested Content

LIVE DEMO
Mirantis Application Platform with Spinnaker
WEBINAR
What's New in Kubernetes 1.10