This post is a dummy walkthrough of neutron services code. I recommend being familiar with the following modules (not a hard requirement, but will help you avoid jumping between this post and other docs):
If you read the headline and your eyebrows raised, you are at the right place. I believe that most of us, who experienced at least one deployment of OpenStack, will agree that deploying OpenStack can be a quite frustrating experience. It doesn’t matter if you are using it for debugging your code or it’s an integral part of your CI environment, deploying OpenStack often with changes, can be complex. Let’s stop for a minute and think why it’s like that.
You run ‘openstack overcloud deploy’ and after a couple of minutes you find out it failed and if that’s not enough, then you open the deployment log just to find a very (very!) long output that doesn’t give you an clue as to why the deployment failed. In the following sections we’ll see how can we get to the root of the problem.
If we tried to explain what OpenFlow is, a possible definition would be: OpenFlow is a protocol for controlling and interacting with forwarding behaviors of switches. It allows us to dynamically control the behavior of the switches in our network. Many SDN (software defined network) and Open Source projects use OpenFlow or support it as a plugin, such as OpenStack Neutron and OpenDaylight.
But It’s hard to grasp what it is, what it solves and how it works only using this brief description. In order to truly understand what is OpenFlow, we need to start from the beginning, before SDN era.
Usually I don’t publish a post on every new project I create, but in this case I believe a lot of people can find it helpful in their learning process. So for the junior networking folks out there, or folks who just enjoy learning more about networking, you might want to take a look on the following page: