[ English | Indonesia | 한국어 (대한민국) | Deutsch | English (United Kingdom) ]

Neutron multiple SDNs¶

Problem Description¶

Currently OpenStack-Helm supports OpenVSwitch as a network virtualization engine. In order to support many possible backends (SDNs), changes are required in neutron chart and in deployment techniques. OpenStack-Helm can support every SDN solution that has Neutron plugin, either core_plugin or mechanism_driver.

The Neutron reference architecture provides mechanism_drivers OpenVSwitch (OVS) and linuxbridge (LB) with ML2 core_plugin framework.

Other networking services provided by Neutron are:

L3 routing - creation of routers
DHCP - auto-assign IP address and DNS info
Metadata- Provide proxy for Nova metadata service

Introducing a new SDN solution should consider how the above services are provided. It may be required to disable the built-in Neutron functionality.

Proposed Change¶

To be able to install Neutron with multiple possible SDNs as networking plugin, Neutron chart should be modified to enable installation of base services with decomposable approach. This means that operator can define which components from base Neutron chart should be installed, and which should not. This plus proper configuration of Neutron chart would enable operator to flexibly provision OpenStack with chosen SDN.

Every Kubernetes manifest inside Neutron chart can be enabled or disabled. That would provide flexibility to the operator, to choose which Neutron components are reusable with different type of SDNs. For example, neutron-server which is serving the API and configuring the database can be used with different types of SDN plugin, and provider of that SDN chart would not need to copy all logic from Neutron base chart to manage the API and database.

The proposes change would be to add in neutron/values.yaml new section with boolean values describing which Neutron's Kubernetes resources should be enabled:

manifests:
  configmap_bin: true
  configmap_etc: true
  daemonset_dhcp_agent: true
  daemonset_l3_agent: true
  daemonset_metadata_agent: true
  daemonset_ovs_agent: true
  daemonset_ovs_db: true
  daemonset_ovs_vswitchd: true
  deployment_server: true
  ingress_server: true
  job_db_init: true
  job_db_sync: true
  job_ks_endpoints: true
  job_ks_service: true
  job_ks_user: true
  pdb_server: true
  secret_db: true
  secret_keystone: true
  service_ingress_server: true
  service_server: true

Then, inside Kubernetes manifests, add global if statement, deciding if given manifest should be declared on Kubernetes API, for example neutron/templates/daemonset-ovs-agent.yaml:

{{- if .Values.manifests.daemonset_ovs_agent }}
# Licensed under the Apache License, Version 2.0 (the "License");

...

        - name: libmodules
      hostPath:
        path: /lib/modules
    - name: run
      hostPath:
        path: /run
{{- end }}

If .Values.manifests.daemonset_ovs_agent will be set to false, neutron ovs agent would not be launched. In that matter, other type of L2 or L3 agent on compute node can be run.

To enable new SDN solution, there should be separate chart created, which would handle the deployment of service, setting up the database and any related networking functionality that SDN is providing.

Use case¶

Let's consider how new SDN can take advantage of disaggregated Neutron services architecture. First assumption is that neutron-server functionality would be common for all SDNs, as it provides networking API, database management and Keystone interaction. Required modifications are:

Configuration in neutron.conf and ml2_conf.ini
Providing the neutron plugin code.

The code can be supplied as modified neutron server image, or plugin can be mounted to original image. The manifests section in neutron/values.yaml should be enabled for below components:

manifests:
  # neutron-server components:
  configmap_bin: true
  configmap_etc: true
  deployment_server: true
  ingress_server: true
  job_db_init: true
  job_db_sync: true
  job_ks_endpoints: true
  job_ks_service: true
  job_ks_user: true
  pdb_server: true
  secret_db: true
  secret_keystone: true
  service_ingress_server: true
  service_server: true

Next, Neutron services like L3 routing, DHCP and metadata serving should be considered. If SDN provides its own implementation, the Neutron's default one should be disabled:

manifests:
  daemonset_dhcp_agent: false
  daemonset_l3_agent: false
  daemonset_metadata_agent: false

Provision of those services should be included inside SDN chart.

The last thing to be considered is VM network virtualization. What engine does SDN use? It is OpenVSwitch, Linux Bridges or l3 routing (no l2 connectivity). If SDN is using the OpenVSwitch, it can take advantage of existing OVS daemonsets. Any modification that would be required to OVS manifests can be included in base Neutron chart as a configurable option. In that way, the features of OVS can be shared between different SDNs. When using the OVS, default Neutron L2 agent should be disabled, but OVS-DB and OVS-vswitchd can be left enabled.

manifests:
  # Neutron L2 agent:
  daemonset_ovs_agent: false
  # OVS tool:
  daemonset_ovs_db: true
  daemonset_ovs_vswitchd: true

Security Impact¶

No security impact.

Performance Impact¶

VM networking performance would be dependent of SDN used.

Alternatives¶

Alternatives to decomposable Neutron chart would be to copy whole Neutron chart and create spin-offs with new SDN enabled. This approach has drawbacks of maintaining the whole neutron chart in many places, and copies of standard services may be out of sync with OSH improvements. This implies constant maintenance effort to up to date.

Implementation¶

Assignee(s)¶

Primary assignees:

korzen (Artur Korzeniewski)
portdirect (Pete Birley)

Work Items¶

Implement decomposable Neutron chart
Add Linux Bridge as first alternative for OVS - separate spec needed.
Add one SDN to see if proposed change is working OK - separate spec needed.

Testing¶

First reasonable testing in gates would be to setup Linux Bridge and check if VM network connectivity is working.

Documentation Impact¶

Documentation of how new SDN can be enabled, how Neutron should be configured. Also, for each new SDN that would be incorporated, the architecture overview should be provided.

Neutron multiple SDNs