From 8423ba6bac4afe5e15b63bf24cdb14a95673aaa6 Mon Sep 17 00:00:00 2001
From: Artur Korzeniewski <artur.korzeniewski@intel.com>
Date: Wed, 26 Jul 2017 09:50:13 +0200
Subject: [PATCH] spec: Neutron multiple SDNs design
Change-Id: I4fd144575ab6f6c63225e0a31d3cc3de396110b3
Implements: blueprint neutron-multiple-sdns
---
doc/source/specs/index.rst | 1 +
doc/source/specs/neutron-multiple-sdns.rst | 225 +++++++++++++++++++++
2 files changed, 226 insertions(+)
create mode 100644 doc/source/specs/neutron-multiple-sdns.rst
diff --git a/doc/source/specs/index.rst b/doc/source/specs/index.rst
index 0a76827e7b..9cef78ca03 100644
--- a/doc/source/specs/index.rst
+++ b/doc/source/specs/index.rst
@@ -8,3 +8,4 @@ Contents:
specifications.rst
template.rst
+ neutron-multiple-sdns.rst
diff --git a/doc/source/specs/neutron-multiple-sdns.rst b/doc/source/specs/neutron-multiple-sdns.rst
new file mode 100644
index 0000000000..0a685b78be
--- /dev/null
+++ b/doc/source/specs/neutron-multiple-sdns.rst
@@ -0,0 +1,225 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+..
+
+=====================
+Neutron multiple SDNs
+=====================
+
+Blueprint:
+neutron-multiple-sdns_
+
+.. _neutron-multiple-sdns: https://blueprints.launchpad.net/openstack-helm/+spec/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 :code:`neutron/values.yaml` new section
+with boolean values describing which Neutron's Kubernetes resources should be
+enabled:
+
+.. code-block:: yaml
+
+ 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
+:code:`neutron/templates/daemonset-ovs-agent.yaml`:
+
+.. code-block:: yaml
+
+ {{- if .Values.manifests.daemonset_ovs_agent }}
+ # Copyright 2017 The Openstack-Helm Authors.
+ #
+ # Licensed under the Apache License, Version 2.0 (the "License");
+
+ ...
+
+ - name: libmodules
+ hostPath:
+ path: /lib/modules
+ - name: run
+ hostPath:
+ path: /run
+ {{- end }}
+
+If :code:`.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 :code:`neutron.conf` and :code:`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 :code:`manifests` section in :code:`neutron/values.yaml`
+should be enabled for below components:
+
+.. code-block:: yaml
+
+ 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:
+
+.. code-block:: yaml
+
+ 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.
+
+.. code-block:: yaml
+
+ 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.
+
+References
+==========