ODL neutron northbound boron planning

feature gaps in ODL and openstack

Isaku Yamahata

OpenDaylight Developer Design Forum Feb 29, 2016

https://wiki.opendaylight.org/view/NeutronNorthbound:Main

etherpad:https://pad.opendaylight.org/p/neutron-northbound-boron-planning�trello board: https://trello.com/b/LhIIQ8Z0/odl-neutronnorthbound

Goal of ODL Neutron Northbound

• To serve dependent projects(openstack service provider)

​

Expected outcome of this session

• reach consensus for Boron tasks/directions(with assignee)
• updated trello boards

version support: openstack vs opendaylight

• openstack
• development(Mitaka)
• stable release(Liberty)
• security release(Kilo)
• -> EOL
• OpenDayLight
• release, SR1-SR4

2 or 3 openstack version?

future

should apply for Mature project review?

incompatible update(mainly yang model)

• Delete IAware* interface
• https://git.opendaylight.org/gerrit/#/c/35505/
• delete backpointers: won’t maintain integrity
• eliminate backpointers instead of maintaining integrity
• e.g. security-group::security-rules
• action: add/remove_router_interface
• interface-attribute
• Bug fixes: the model was broken from the beginning
• there isn’t any good way to maintain compatibilities
• catching up openstack neutron change
• probably compatibility can be maintain by augmentation

Security Group:

protocol conversion: string into integer

• neutron accepts both string(tcp, udp, icmp, ...) and integer
• string name constantly is being added.
• ODL doesn’t want to follow it.
• networking-odl converts protocol string into integer

neutron extension

L3 feature

services

New coming features in Mitaka

• proposed features may or may not make it
• http://specs.openstack.org/openstack/neutron-specs/specs/mitaka/

​

add-port-timestamp.rst�add-tags-to-core-resources.rst�address-scopes.rst�adopt-oslo-guru-reports.rst�availability-zone.rst�bgp-dynamic-routing.rst�external-dns-resolution.rst�fwaas-api-2.0.rst�get-me-a-network.rst��

improve-dvr-l3-agent-binding.rst�lbaas-driver-vip-delegation.rst�lbaas-l7-rules.rst�network-ip-availability-api.rst�neutron-flavor-framework-templates.rst�neutron-lib.rst�rbac-qos-policies.rst�restructure-l2-agent.rst�unaddressed-port.rst�vlan-aware-vms.rst

agent_db

host-id

agent-type

config

key:host-id

host-type

config

Neutron

ODL

Neutron Northbound

ODL

openstack service provider

networking-odl

OVSDB

host-id:host-type:config

port binding

router scheduling

startup

On port binding: refer to agent_db for config on host-id

on startup of networking-odl

and periodically networking-odl polls ODL MD-SAL via http.

Later phase, introduce callback from ODL to networking-odl

nova

Subclass of mech_agent.py

• binding:vnic_type,
• binding:profile
• binding:host_id

node related configurations

• introduce new model to describe config/capability of each compute/network node
• corresponding to openstack neutron agent API
• neutron agent-list
• Values
• string host-id (not uuid)
• by default, $(hostname)
• string host-type
• string config
• Key: host-id + host-type
• ODL patch: https://git.opendaylight.org/gerrit/#/c/36767/

node related configurations

• String config
• Json as string

{� 'supported_vnic_types': [VNIC_NORMAL, VNIC_DIRECT, ...],� 'allowed_network_types': [TYPE_LOCAL, TYPE_FLAT, TYPE_VLAN, TYPE_VXLAN...],� 'bridge_mappings': [<physical_network>:<bridge>, ...],� 'supported_vnic_types': {VNIC_NORMAL: vif_details_normal, ...},� 'vif_type': VIF_TYPE_VHOST_USER,� 'vif_details': {CAP_PORT_FILTER: False, VHOST_USER_SOCKET: sock_path, ...},� 'vlan_transparency': false,

….� }

Local config: bad

​

port binding and agent

• agent_db
• (ab)use agent_db and its scheduler
• the current code closely ties host/functionality to agent/agent_type
• agent: functionality,
• neutron normal case: hostid -> agent -> config
• what we want: hostid -> config
• someone needs to populate agent_db table
• on ODL side, yang model:
• default values:
• hostid -> config
• networking-odl populates it: ovsdb in node -> ODL -> networking-odl -> db in neutron
• networking-odl should do it?
• Currently no callback from ODL to networking-odl
• at first phase: networking-odl polls new node
• later: odl up-calls networking-odl to populate it: MD-SAL DCN(Data Chage Notification) via http(websocket?)

networking-node without l3-agent

• for shared SNAT
• distributed shared SNAT is impractical. Even neutron with ovs-agent hasn’t solved this.
• At least as first phase, centralized SNAT will be adopted.
• (ab)use agent_db

dhcp, radvd and vrrp

• agent to spawn dnsmasq(dhcpd), radvd(RFC 2461), keepalived(vrrp)
• http://www.thekelleys.org.uk/dnsmasq/doc.html
• http://www.litech.org/radvd/
• http://keepalived.org/
• Do we want to re-implement those functionalities in ODL?
• If no, agent (l3-agent - l3 functionarity) is needed

capability reporting

• openstack service provider reports its capability
• networking-odl reads it on startup
• something similar to extension of neutron api(neutron ext-list)

rolling upgrade

How to upgrade ODL without downtime

What’s the procedure to upgrade

1. upgrade neutron/networking-odl
2. upgrade opendaylight
1. networking-odl will notice the ODL upgrade

​

• Put transition logic on neutron/networking-odl side.
• networking-odl automatically detect upgrade.
• ODL returns version mismatch error to networking-odl?
• re-negotiate on http bad request?

​

1. upgrade opendaylight
2. upgrade neutron/networking-odl

​

• ODL neutron northbound need to maintain compatibility from networking-odl <ver N - 1> -> networking-odl <ver N>

backup