Inside neutron 2

Deep Dive into Neutron
by Yong Sheng Gong

caveats
●

developers oriented
–

●

many codes and UML diagrams

the snapshot of current neutron code
–

evolution of neutron codes will obsolete some
contents of this presentation

Coming sessions about Neutron
●

Load balancing in neutron

Thursday November 7, 2013 4:30pm - 5:10pm, SkyCity Grand Ballroom C (SkyCity Marriott Hotel)

●

How to Write a Neutron Plugin, If You Really Need to

Thursday November 7, 2013 5:20pm - 6:00pm ,SkyCity Grand Ballroom C (SkyCity Marriott Hotel)

●

OpenStack Neutron Modular Layer 2 Plugin Deep Dive

Friday November 8, 2013 11:00am - 11:40am, Expo Breakout Room 2 (AsiaWorld-Expo)

●

Neutron Hybrid Deployment and Performance Analysis

Friday November 8, 2013 1:30pm - 2:10pm, Expo Breakout Room 2 (AsiaWorld-Expo)

●

Neutron Network Namespaces and IPtables: Technical Deep Dive

Friday November 8, 2013 4:10pm - 4:50pm, Expo Breakout Room 2 (AsiaWorld-Expo)

Contents
●

the process of neutron start

●

the normal steps to process a request

●

Start ML2 plugin

●

message queues in Neutron

●

interaction with nova compute

●

To debug the Neutron

related skills
●

WSGI

WSGI is the Web Server Gateway Interface. It is a specification for web servers and
application servers to communicate with web applications.
●

paste deploy

Paste Deployment is a system for finding and configuring WSGI applications and servers. The primary
interaction with Paste Deploy is through its configuration files.
●

Python Routes

Routes is a Python re-implementation of the Rails routes system for mapping URLs to
application actions, and conversely to generate URLs. Routes makes it easy to create pretty
and concise URLs that are RESTful with little effort.
●

peCan

Will we change to pecan? see design summit session Neutron API Framework Replacement

Layer diagram of Neutron server
Core REST API

Extension A REST
API

Extension … REST
API

AuthN/AuthZ/Input Validation/Output view
Core Plugin Interface

Core Plugin
(Vendor
specific)

Service A Plugin
Interface

Service A Plugin

Service … Plugin
Interface

Service … Plugin

agents

paste application and filters
[composite:neutron]
use = egg:Paste#urlmap
/: neutronversions
/v2.0: neutronapi_v2_0
[composite:neutronapi_v2_0]
use = call:neutron.auth:pipeline_factory
keystone = authtoken keystonecontext extensions neutronapiapp_v2_0
[filter:keystonecontext]
paste.filter_factory = neutron.auth:NeutronKeystoneContext.factory
[filter:authtoken]
paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
[filter:extensions]
paste.filter_factory =
neutron.api.extensions:plugin_aware_extension_middleware_factory
[app:neutronversions]
paste.app_factory = neutron.api.versions:Versions.factory
[app:neutronapiapp_v2_0]
paste.app_factory = neutron.api.v2.router:APIRouter.factory

main entry point
neutron/server/__init__.py: main()
1.config.parse(sys.argv[1:])

--config-file neutron.conf --config-file xxx.ini

2.neutron/common/config.py:load_paste_app(“neutron”)
2.1 neutron/auth.py:pipeline_factory()
2.1.1 neutron/api/v2/router.py:APIRouter.factory()
2.1.2 neutron/api/extensions.py:
plugin_aware_extension_middleware_factory()
2.1.3 neutron.auth:NeutronKeystoneContext.factory()
2.1.4 keystoneclient.middleware.auth_token:filter_factory()

filters and application pipeline
extensions
URL is
declared here?

URL
request

Process

authtoken

No

neutronapiapp_v2_0

keystonecontext

No, return
HTTPNotFound

URL is
declared here?

Response

Process

neutronapiapp_v2_0: load plugins
neutron/api/v2/router.py:APIRouter.factory()
1. __init__()
1.1 plugin = manager.NeutronManager.get_plugin()
1.1.1 neutron/manager.py:__init__()
A 1.1.1.1 create core plugin instance
B 1.1.1.2

neutron/manager.py:_load_service_plugins()

neutron.conf:
service_plugins = ...
core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
NeutronManager
:service_plugins =
{“CORE”: ml2_plugin,
"LOADBALANCER":xxx,
...}

what are plugins and extensions
●

extensions are about resources and the actions
on them
@classmethod
def get_resources(cls):
for resource_name in ['router', 'floatingip']:
...
controller = base.create_resource(
collection_name, resource_name, plugin...)

ex = ResourceExtension(collection_name, controller,
member_actions...)
●

plugins are used to support the resources
supported_extension_aliases = ["router", "ext-gw-mode",
"extraroute",
"l3_agent_scheduler"]
def update_router(self, context, id, router):
def get_router(self, context, id, fields=None):

neutronapiapp_v2_0: load extensions
1. __init__()
1.2 extensions.PluginAwareExtensionManager.get_instance()
1.2.1 extensions.py:get_extensions_path()
1.2.2 PluginAwareExtensionManager.__init__(paths, plugins)
1.2.2.1 _load_all_extensions()
for each path in paths
_load_all_extensions_from_path(path A
)
add_extension(ext)

neutron standard
extension plus ones
specified by
api_extensions_path= in
neutron.conf

_check_extension(ext)
B
check each python module name
under the path, and capitalize the
first letter of the module name to
find the class in it, excluding the
1. check if the potential extension has implemented the
modules starting with "_".
needed functions
2. check if one of plugins supports it. plugin's
supported_extension_aliases attribute defines what
extensions it supports.

neutronapiapp_v2_0: install core resources
1. __init__()
1.2 PluginAwareExtensionManager.get_instance()
1.3 install core resources

neutron/api/v2/router.py:
RESOURCES = {'network': 'networks',
'subnet': 'subnets',
'port': 'ports'}

After it, core resources URLs, i.e. Core
Resource API, are installed and exposed.

extension filter: assemble extensions
2.1.2 neutron/api/extensions.py:plugin_aware_extension_middleware_factory()

ext_mgr = PluginAwareExtensionManager.get_instance()
return ExtensionMiddleware(app, ext_mgr=ext_mgr)

After it, all extension URLs, or
extensions on core resources are
installed and exposed

Layer diagram
Core REST API

Extension A REST
API

Extension … REST
API

AuthN/AuthZ/Input Validation/Output view
Core Plugin Interface

Core Plugin
(Vendor
specific)

Service A Plugin
Interface

Service A Plugin

Service … Plugin
Interface

Service … Plugin

agents

URL processing continued
notification to ceilometer
also happens here
action is link create,
update, show, index or delete

handler_fun is like create_net,
list_nets function of plugins

ML2 Plugin
●

●

●

●

simultaneously utilize the variety of layer 2
networking technologies found in complex real-world
data centers
It currently works with the existing openvswitch,
linuxbridge, and hyperv L2 agents
The ml2 framework is also intended to greatly
simplify adding support for new L2 networking
technologies
consists of network types and mechanisms

https://wiki.openstack.org/wiki/Neutron/ML2#ML2_Drivers

Type and mechanism drivers in setup.cfg
neutron.ml2.type_drivers =
flat = neutron.plugins.ml2.drivers.type_flat:FlatTypeDriver
local = neutron.plugins.ml2.drivers.type_local:LocalTypeDriver
vlan = neutron.plugins.ml2.drivers.type_vlan:VlanTypeDriver
gre = neutron.plugins.ml2.drivers.type_gre:GreTypeDriver
vxlan = neutron.plugins.ml2.drivers.type_vxlan:VxlanTypeDriver
neutron.ml2.mechanism_drivers =
linuxbridge = neutron.plugins.ml2.drivers.mech_linuxbridge:LinuxbridgeMechanismDriver
openvswitch = neutron.plugins.ml2.drivers.mech_openvswitch:OpenvswitchMechanismDriver
hyperv = neutron.plugins.ml2.drivers.mech_hyperv:HypervMechanismDriver
ncs = neutron.plugins.ml2.drivers.mechanism_ncs:NCSMechanismDriver
arista = neutron.plugins.ml2.drivers.mech_arista.mechanism_arista:AristaDriver
cisco_nexus = neutron.plugins.ml2.drivers.cisco.mech_cisco_nexus:CiscoNexusMechanismDriver
l2population = neutron.plugins.ml2.drivers.l2pop.mech_driver:L2populationMechanismDriver

Configuration for types in ml2.ini
neutron-server --config-file /etc/neutron/neutron.conf --config-file
/etc/neutron/ml2.ini
[ml2]
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers = openvswitch,linuxbridge
tenant_network_types = vlan,gre,vxlan
[ml2_type_flat]
flat_networks = physnet1,physnet2
[ml2_type_vlan]
network_vlan_ranges = physnet1:1000:2999,physnet2
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
vni_ranges = 1001:2000

__init__ of ML2
neutron/manager.py:__init__()
create core plugin instance [core_plugin=]

which will read
configuration in ml2.ini

RPC structure of ML2

deal with RPC
from agents,
include DHCP agent

notify the L2 agents

callbacks:
receive the message
from plugins

communicate
with plugin

RPC of L2 agent:
ovs neutron agent

messages:
Plugin to agent
Plugins

Exchanges

Queues

L2 Agents

L2 Agents

Exchanges

Queues

Plugins

RPC messages
L2 Agent to Plugin

Neutron
Server

Exchanges

Queues

DHCP
Agents

Messages from Neutron
server to DHCP agent

RPC messages
DHCP Agent to Plugin
DHCP
Agents

Exchanges

Queues

Plugin

Some Neutron options in Nova.conf
●

network_api_class = nova.network.neutronv2.api.API

●

neutron_url = http://172.16.108.1:9696

●

neutron_region_name = RegionOne

●

neutron_admin_tenant_name = service

●

neutron_auth_strategy = keystone

●

neutron_admin_auth_url = http://172.16.108.1:35357/v2.0

●

neutron_admin_password = password

●

neutron_admin_username = neutron

●

libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtGenericVIFDriver

interaction to boot VM (OVS bridge)

debug Neutron
https://wiki.openstack.org/wiki/NeutronDevelopment
● Eclipse pydev to debug neutron server
●

neutron/server/__init__.py:
●
change eventlet.monkey_patch() To:
eventlet.monkey_patch(os=False, thread=False)
– and then create a python run/debug configuration with the
correct parameter such as "--config-file
/etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/ml2_conf.ini"
–

ipdb

●

add the following line to the
neutron/server/__init__.py:

import ipdb; ipdb.set_trace()
●

start the neutron server

Inside neutron 2

More Related Content

Inside neutron 2