spec: Neutron multiple SDNs design
Change-Id: I4fd144575ab6f6c63225e0a31d3cc3de396110b3 Implements: blueprint neutron-multiple-sdns
This commit is contained in:
Artur Korzeniewski
parent
ddc3ca4b23
commit
8423ba6bac
@ -8,3 +8,4 @@ Contents:
|
||||
|
||||
specifications.rst
|
||||
template.rst
|
||||
neutron-multiple-sdns.rst
|
||||
|
||||
225
doc/source/specs/neutron-multiple-sdns.rst
Normal file
225
doc/source/specs/neutron-multiple-sdns.rst
Normal file
@ -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
|
||||
==========
|
||||
Loading…
Reference in New Issue
Block a user