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 Kilo(security Liberty(stable) Mitaka Newton(future) Ocata supported) (development) Helium Lithium(SR3) Beryllium(stable) Boron Carbon(future) (SR4) (development): LTS
openstack security openstack stable openstack support release development opendaylight SR - - should maintain? engineering resource? opendaylight stable - No major activity test by openstack CI release opendaylight should maintain? TODO: test by opensatck CI development engineering test by ODL CI test by ODL CI(TODO) resource? Developer major focus
2 or 3 openstack version? future Kilo Liberty Mitaka Newton Ocata Hellium ? Lithium ? ? Beryllium ? ? ? Boron ? ? Carbon ? ?
should apply for Mature project review?
in compatible update(mainly yang model) ● Delete IAware* interface project Ready to eliminate I*Aware? ○ https://git.opendaylight.org/gerrit/#/c/35505/ ● delete backpointers: won’t maintain integrity ovsdb/netvirt Yes ○ eliminate backpointers instead of maintaining integrity GroupBasedPolicy No ○ e.g. security-group::security-rules ○ action: add/remove_router_interface VTN Yes ■ interface-attribute LispFlowMapping No ● Bug fixes: the model was broken from the beginning NIC Yes ○ 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 features/extension supported by neutron supported by ovsdb/netvirt comment northbound? GBP, lispflowmapper, vtn, nic providernet yes No common model to describe providernet on each It requires a way for cloud admin to compute/network node is tell how compute/network node is connected physically 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 openstack neutron router_availability_zone No No
L3 feature feature supported by neutron supported by netvirt, GBP, reference implementation comment northbound? lispflowmapper, vtn, nic (ovs-agent, l3-agent) DVR east-west - Yes Yes DVR north-south: foating ip - Yes Yes (DNAT) DVR north-south: shared needs network node No Yes: keepalived SNAT scheduling HA with VRRP distributed SNAT centralized shared SNAT scneduler ipv6 router advertisement - No Yes radvd RFC2461 IPv6 SLAAC - No yes rfc4862 rfc7527 metadata (amazon API http: - No meta data agent This isn’t necessary as //169.254.169.254 meta data proxy on dhcp agetn with metadata /latest/meta-data/) networking node server
services features/extension supported by neutron support by netvirt, GBP, comment northbound? lispflowmapper, vtn, nic 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 no no service) 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/ improve-dvr-l3-agent-binding.rst add-port-timestamp.rst lbaas-driver-vip-delegation.rst add-tags-to-core-resources.rst lbaas-l7-rules.rst address-scopes.rst network-ip-availability-api.rst adopt-oslo-guru-reports.rst neutron-flavor-framework-templates.rst availability-zone.rst neutron-lib.rst bgp-dynamic-routing.rst rbac-qos-policies.rst external-dns-resolution.rst restructure-l2-agent.rst fwaas-api-2.0.rst unaddressed-port.rst get-me-a-network.rst vlan-aware-vms.rst
networking-odl Neutron ODL ODL Neutron Northbound openstack service provider agent_db key:host-id host config config on startup of networking-odl and periodically networking-odl polls ODL MD-SAL via http. Later phase, introduce callback startup from ODL to networking-odl nova port binding router scheduling On port binding: refer to agent_db for config on host-id OVSDB host-id:config
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 ○ 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 dhcp agent dhcp l3 agent router advertisement(radvd) vrrp(keepalived)
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 1. upgrade opendaylight 2. upgrade opendaylight 2. upgrade neutron/networking-odl a. networking-odl will notice the ODL upgrade ● ODL neutron northbound need to maintain compatibility from ● Put transition logic on networking-odl <ver N - 1> -> neutron/networking-odl side. networking-odl <ver N> ● networking-odl automatically detect upgrade. ○ ODL returns version mismatch error to networking-odl? ○ re-negotiate on http bad request?
backup
Recommend
More recommend
