ODL neutron northbound boron planning feature gaps in ODL and - - PowerPoint PPT Presentation

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

• penstack

○ development(Mitaka) ○ stable release(Liberty) ○ security release(Kilo) ○

• > EOL
• OpenDayLight

○ release, SR1-SR4

version support: openstack vs opendaylight

Kilo(security supported) Liberty(stable) Mitaka (development) Newton(future) Ocata Helium (SR4) Lithium(SR3) Beryllium(stable) Boron (development): LTS Carbon(future)

• penstack security

support

• penstack stable

release

• penstack

development

• pendaylight SR
• should maintain?

engineering resource?

• pendaylight stable

release

• No major activity

test by openstack CI

• pendaylight

development should maintain? engineering resource? TODO: test by ODL CI test by opensatck CI test by ODL CI(TODO) Developer major focus

2 or 3 openstack version?

Kilo Liberty Mitaka Newton Ocata Hellium ? Lithium ? ? Beryllium ? ? ? Boron ? ? Carbon ? ? 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

project Ready to eliminate I*Aware?

• vsdb/netvirt

Yes GroupBasedPolicy No VTN Yes LispFlowMapping No NIC Yes

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

features/extension supported by neutron northbound? supported by ovsdb/netvirt GBP, lispflowmapper, vtn, nic comment providernet yes

It requires a way for cloud admin to tell how compute/network node is connected physically

No

common model to describe providernet on each compute/network node is necessary

extraroute Yes Yes metering Yes No netmtu No No network_availability_zone No No portsecurity No No qos No No

5 qos policies in neutron with ovs

vlantransparent No No vlan trunking(vlan aware vms) No No

this feature is still under development in

• penstack neutron

router_availability_zone No No

neutron extension

L3 feature

feature supported by neutron northbound? supported by netvirt, GBP, lispflowmapper, vtn, nic reference implementation (ovs-agent, l3-agent) comment DVR east-west

• Yes

Yes DVR north-south: foating ip (DNAT)

• Yes

Yes DVR north-south: shared SNAT distributed SNAT needs network node scheduling No Yes: HA with VRRP centralized shared SNAT scneduler keepalived ipv6 router advertisement

• No

Yes radvd RFC2461 IPv6 SLAAC

• No

yes rfc4862 rfc7527 metadata (amazon API http: //169.254.169.254 /latest/meta-data/)

• No

meta data agent meta data proxy on networking node This isn’t necessary as dhcp agetn with metadata server

services

features/extension supported by neutron northbound? support by netvirt, GBP, lispflowmapper, vtn, nic comment LBaaSv1 yes yes LBaaSv2 no no FWaaS no no VPNaaS no no bgpvpn yes yes by vpnservice networking-l2gw yes yes there is ODL project networking-taas(tap as a service) no no networking-sfc no no

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 config key:host-id config Neutron ODL Neutron Northbound ODL

• penstack service provider

networking-odl OVSDB host-id:config port binding router scheduling startup On port binding: refer to agent_db for config on host-id

• n startup of networking-odl

and periodically networking-odl polls ODL MD-SAL via http. Later phase, introduce callback from ODL to networking-odl nova

node related configurations

• introduce new model to describe config/capability of each compute/network

node

○ corresponding to openstack neutron agent API ○ neutron agent-list

• key: host-id string(not uuid)

○ by default, $(hostname)

• value: string

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

○

• n 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

dhcp agent dhcp l3 agent router advertisement(radvd) vrrp(keepalived)

capability reporting

• penstack 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 a. 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