Merge "Alphabetize some of the admin and contrib docs"
This commit is contained in:
commit
4a6eae9a84
|
@ -1,7 +1,7 @@
|
|||
.. _config-address-scopes:
|
||||
|
||||
==============
|
||||
Address scopes
|
||||
Address Scopes
|
||||
==============
|
||||
|
||||
Address scopes build from subnet pools. While subnet pools provide a mechanism
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-az:
|
||||
|
||||
==================
|
||||
Availability zones
|
||||
Availability Zones
|
||||
==================
|
||||
|
||||
An availability zone groups network nodes that run services like DHCP, L3, FW,
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-bgp-dynamic-routing:
|
||||
|
||||
===================
|
||||
BGP dynamic routing
|
||||
BGP Dynamic Routing
|
||||
===================
|
||||
|
||||
BGP dynamic routing enables advertisement of self-service (private) network
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _config-bgp-floating-ip-over-l2-segmented-network:
|
||||
|
||||
==========================================
|
||||
BGP floating IPs over l2 segmented network
|
||||
==========================================
|
||||
===========================================
|
||||
BGP Floating IPs over L2 Segmented Networks
|
||||
===========================================
|
||||
|
||||
The general principle is that L2 connectivity will be bound to a single rack.
|
||||
Everything outside the switches of the rack will be routed using BGP. To
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _config-dhcp-ha:
|
||||
|
||||
==========================
|
||||
High-availability for DHCP
|
||||
==========================
|
||||
======================
|
||||
DHCP High-availability
|
||||
======================
|
||||
|
||||
This section describes how to use the agent management (alias agent) and
|
||||
scheduler (alias agent_scheduler) extensions for DHCP agents
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-dns-int-ext-serv:
|
||||
|
||||
========================================
|
||||
DNS integration with an external service
|
||||
DNS Integration with an External Service
|
||||
========================================
|
||||
|
||||
This page serves as a guide for how to use the DNS integration functionality of
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-dns-int:
|
||||
|
||||
===============
|
||||
DNS integration
|
||||
DNS Integration
|
||||
===============
|
||||
|
||||
This page serves as a guide for how to use the DNS integration functionality of
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-dns-res:
|
||||
|
||||
============================
|
||||
DNS resolution for instances
|
||||
DNS Resolution for Instances
|
||||
============================
|
||||
|
||||
The Networking service offers several methods to configure name
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-experimental-framework:
|
||||
|
||||
===============================
|
||||
Experimental features framework
|
||||
Experimental Features Framework
|
||||
===============================
|
||||
|
||||
Some Neutron features are not supported because the community doesn't have
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-fip-port-forwardings:
|
||||
|
||||
===========================
|
||||
Floating IP port forwarding
|
||||
Floating IP Port Forwarding
|
||||
===========================
|
||||
|
||||
Floating IP port forwarding enables users to forward traffic from a
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-ipam:
|
||||
|
||||
==================
|
||||
IPAM configuration
|
||||
IPAM Configuration
|
||||
==================
|
||||
|
||||
Starting with the Liberty release, OpenStack Networking includes a pluggable
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _config-logging:
|
||||
|
||||
================================
|
||||
Neutron Packet Logging Framework
|
||||
================================
|
||||
========================
|
||||
Packet Logging Framework
|
||||
========================
|
||||
|
||||
Packet logging service is designed as a Neutron plug-in that captures network
|
||||
packets for relevant resources (e.g. security group or firewall group) when the
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-macvtap:
|
||||
|
||||
========================
|
||||
Macvtap mechanism driver
|
||||
Macvtap Mechanism Driver
|
||||
========================
|
||||
|
||||
The Macvtap mechanism driver for the ML2 plug-in generally increases
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-metadata-caching:
|
||||
|
||||
========================
|
||||
Metadata service caching
|
||||
Metadata Service Caching
|
||||
========================
|
||||
|
||||
The OpenStack Networking service proxies requests that VMs send to the
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-metadata-rate-limiting:
|
||||
|
||||
====================================
|
||||
Metadata service query rate limiting
|
||||
Metadata Service Query Rate-limiting
|
||||
====================================
|
||||
|
||||
The OpenStack Networking service proxies the requests that VMs send to the
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-plugin-ml2:
|
||||
|
||||
===========
|
||||
ML2 plug-in
|
||||
ML2 Plug-in
|
||||
===========
|
||||
|
||||
Architecture
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-mtu:
|
||||
|
||||
==================
|
||||
MTU considerations
|
||||
MTU Considerations
|
||||
==================
|
||||
|
||||
The Networking service uses the MTU of the underlying physical network to
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-ndp-proxy:
|
||||
|
||||
=========
|
||||
NDP proxy
|
||||
NDP Proxy
|
||||
=========
|
||||
|
||||
If NDP proxy is set on a router, it is used to publish IPv6 addresses to
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-network-segment-ranges:
|
||||
|
||||
======================
|
||||
Network segment ranges
|
||||
Network Segment Ranges
|
||||
======================
|
||||
|
||||
The network segment range service exposes the segment range management to be
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-ovs-dpdk:
|
||||
|
||||
===============================
|
||||
Open vSwitch with DPDK datapath
|
||||
Open vSwitch with DPDK Datapath
|
||||
===============================
|
||||
|
||||
This page serves as a guide for how to use the OVS with DPDK datapath
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-ovs-offload:
|
||||
|
||||
================================
|
||||
Open vSwitch hardware offloading
|
||||
Open vSwitch Hardware Offloading
|
||||
================================
|
||||
|
||||
The purpose of this page is to describe how to enable Open vSwitch hardware
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-ovsfwdriver:
|
||||
|
||||
===================================
|
||||
Native Open vSwitch firewall driver
|
||||
Open vSwitch Native Firewall Driver
|
||||
===================================
|
||||
|
||||
Historically, Open vSwitch (OVS) could not interact directly with *iptables*
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-service-subnets:
|
||||
|
||||
===============
|
||||
Service subnets
|
||||
Service Subnets
|
||||
===============
|
||||
|
||||
Service subnets enable operators to define valid port types for each
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-services-agent:
|
||||
|
||||
===================
|
||||
Services and agents
|
||||
Agents and Services
|
||||
===================
|
||||
|
||||
A usual neutron setup consists of multiple services and agents running on one
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _adv-config-sfc:
|
||||
|
||||
=========================
|
||||
Service function chaining
|
||||
Service Function Chaining
|
||||
=========================
|
||||
|
||||
Service function chain (SFC) essentially refers to the
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _config-subnet-onboard:
|
||||
|
||||
==============
|
||||
Subnet onboard
|
||||
==============
|
||||
=================
|
||||
Subnet Onboarding
|
||||
=================
|
||||
|
||||
The subnet onboard feature allows you to take existing subnets that have been
|
||||
created outside of a subnet pool and move them into an existing subnet pool.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _config-subnet-pools:
|
||||
|
||||
============
|
||||
Subnet pools
|
||||
Subnet Pools
|
||||
============
|
||||
|
||||
Subnet pools have been made available since the Kilo release. It is a simple
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
.. _config-wsgi:
|
||||
|
||||
Installing Neutron API via WSGI
|
||||
WSGI Usage with the Neutron API
|
||||
===============================
|
||||
|
||||
This document is a guide to deploying neutron using WSGI. There are two ways to
|
||||
This document is a guide to deploying Neutron using WSGI. There are two ways to
|
||||
deploy using WSGI: ``uwsgi`` and Apache ``mod_wsgi``.
|
||||
|
||||
Please note that if you intend to use mode uwsgi, you should install the
|
||||
|
|
|
@ -7,12 +7,12 @@ Configuration
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
config-services-agent
|
||||
config-ml2
|
||||
config-address-scopes
|
||||
config-services-agent
|
||||
config-auto-allocation
|
||||
config-az
|
||||
config-bgp-dynamic-routing
|
||||
config-bgp-floating-ip-over-l2-segmented-network
|
||||
config-dhcp-ha
|
||||
config-dns-int
|
||||
config-dns-int-ext-serv
|
||||
|
@ -22,27 +22,27 @@ Configuration
|
|||
config-fip-port-forwardings
|
||||
config-ipam
|
||||
config-ipv6
|
||||
config-logging
|
||||
config-macvtap
|
||||
config-metadata-caching
|
||||
config-metadata-rate-limiting
|
||||
config-ml2
|
||||
config-mtu
|
||||
config-ndp-proxy
|
||||
config-network-segment-ranges
|
||||
config-ovs-dpdk
|
||||
config-ovs-offload
|
||||
config-ovsfwdriver
|
||||
config-logging
|
||||
config-qos
|
||||
config-qos-min-bw
|
||||
config-qos-min-pps
|
||||
config-rbac
|
||||
config-routed-networks
|
||||
config-sfc
|
||||
config-sriov
|
||||
config-subnet-pools
|
||||
config-subnet-onboard
|
||||
config-sfc
|
||||
config-service-subnets
|
||||
config-bgp-floating-ip-over-l2-segmented-network
|
||||
config-subnet-onboard
|
||||
config-subnet-pools
|
||||
config-trunking
|
||||
config-wsgi
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
Subnet Pools and Address Scopes
|
||||
Address Scopes and Subnet Pools
|
||||
===============================
|
||||
|
||||
This page discusses subnet pools and address scopes
|
||||
|
|
|
@ -21,7 +21,7 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Agent extensions
|
||||
Agent Extensions
|
||||
================
|
||||
|
||||
All reference agents utilize a common extension mechanism that allows for the
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Neutron WSGI/HTTP API layer
|
||||
===========================
|
||||
API Layer for Neutron WSGI/HTTP
|
||||
===============================
|
||||
|
||||
This section will cover the internals of Neutron's HTTP API, and the classes
|
||||
in Neutron that can be used to create Extensions to the Neutron API.
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Profiling Neutron Code
|
||||
======================
|
||||
Code Profiling
|
||||
==============
|
||||
|
||||
As more functionality is added to Neutron over time, efforts to improve
|
||||
performance become more difficult, given the rising complexity of the code.
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Neutron Database Layer
|
||||
======================
|
||||
Database Layer
|
||||
==============
|
||||
|
||||
This section contains some common information that will be useful for
|
||||
developers that need to do some database changes as well as to execute queries
|
||||
|
|
|
@ -12,8 +12,8 @@
|
|||
under the License.
|
||||
|
||||
|
||||
Relocation of Database Models
|
||||
=============================
|
||||
Database Models Relocation
|
||||
==========================
|
||||
|
||||
This document is intended to track and notify developers that db models in
|
||||
neutron will be centralized and moved to a new tree under neutron/db/models.
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Keep DNS Nameserver Order Consistency In Neutron
|
||||
================================================
|
||||
DNS Nameserver Order Consistency
|
||||
================================
|
||||
|
||||
In Neutron subnets, DNS nameservers are given priority when created or updated.
|
||||
This means if you create a subnet with multiple DNS servers, the order will
|
||||
|
|
|
@ -12,8 +12,8 @@
|
|||
under the License.
|
||||
|
||||
|
||||
Integration with external DNS services
|
||||
======================================
|
||||
External DNS Service Integration
|
||||
================================
|
||||
|
||||
Since the Mitaka release, neutron has an interface defined to interact with an
|
||||
external DNS service. This interface is based on an abstract driver that can be
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Neutron Stadium i18n
|
||||
====================
|
||||
i18n for the Neutron Stadium
|
||||
============================
|
||||
|
||||
* Refer to oslo_i18n documentation for the general mechanisms that should
|
||||
be used: https://docs.openstack.org/oslo.i18n/latest/user/usage.html
|
||||
|
|
|
@ -54,6 +54,7 @@ Neutron Internals
|
|||
objects_usage
|
||||
openvswitch_agent
|
||||
openvswitch_firewall
|
||||
ovn/index
|
||||
ovs_vhostuser
|
||||
plugin-api
|
||||
policy
|
||||
|
@ -70,4 +71,3 @@ Neutron Internals
|
|||
sriov_nic_agent
|
||||
tag
|
||||
upgrade
|
||||
ovn/index
|
||||
|
|
|
@ -21,7 +21,7 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
L2 agent extensions
|
||||
L2 Agent Extensions
|
||||
===================
|
||||
|
||||
L2 agent extensions are part of a generalized L2/L3 extension framework. See
|
||||
|
|
|
@ -21,7 +21,7 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
L3 agent extensions
|
||||
L3 Agent Extensions
|
||||
===================
|
||||
|
||||
L3 agent extensions are part of a generalized L2/L3 extension framework. See
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Layer 3 Networking in Neutron - via Layer 3 agent & OpenVSwitch
|
||||
===============================================================
|
||||
Layer 3 Networking via Layer 3 & OpenVSwitch Agents
|
||||
===================================================
|
||||
|
||||
This page discusses the usage of Neutron with Layer 3 functionality enabled.
|
||||
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
L2 Networking with Linux Bridge
|
||||
===============================
|
||||
Linux Bridge Networking L2 Agent
|
||||
================================
|
||||
|
||||
This Agent uses the `Linux Bridge
|
||||
<http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge>`_ to
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Objects in neutron
|
||||
==================
|
||||
Objects
|
||||
=======
|
||||
|
||||
Object versioning is a key concept in achieving rolling upgrades. Since its
|
||||
initial implementation by the nova community, a versioned object model has been
|
||||
|
|
|
@ -20,7 +20,7 @@
|
|||
''''''' Heading 4
|
||||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
Neutron Open vSwitch vhost-user support
|
||||
Neutron Open vSwitch vhost-user Support
|
||||
=======================================
|
||||
|
||||
Neutron supports using Open vSwitch + DPDK vhost-user interfaces directly in
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Authorization Policy Enforcement
|
||||
================================
|
||||
Policy Enforcement and Authorization
|
||||
====================================
|
||||
|
||||
As most OpenStack projects, Neutron leverages oslo_policy [#]_. However, since
|
||||
Neutron loves to be special and complicate every developer's life, it also
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Composite Object Status via Provisioning Blocks
|
||||
===============================================
|
||||
Provisioning Blocks in relation to Composite Object Status
|
||||
==========================================================
|
||||
|
||||
We use the STATUS field on objects to indicate when a resource is ready
|
||||
by setting it to ACTIVE so external systems know when it's safe to use
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Neutron RPC API Layer
|
||||
=====================
|
||||
RPC API Layer
|
||||
=============
|
||||
|
||||
Neutron uses the oslo.messaging library to provide an internal communication
|
||||
channel between Neutron services. This communication is typically done via
|
||||
|
|
|
@ -23,8 +23,8 @@
|
|||
|
||||
.. _rpc_callbacks:
|
||||
|
||||
Neutron Messaging Callback System
|
||||
=================================
|
||||
RPC Messaging Callback System
|
||||
=============================
|
||||
|
||||
Neutron already has a `callback system
|
||||
<https://docs.openstack.org/neutron-lib/latest/contributor/callbacks.html>`_
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Guided Tour: The Neutron Security Group API
|
||||
===========================================
|
||||
Security Group API
|
||||
==================
|
||||
|
||||
https://wiki.openstack.org/wiki/Neutron/SecurityGroups
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@
|
|||
under the License.
|
||||
|
||||
|
||||
Segments extension
|
||||
Segments Extension
|
||||
==================
|
||||
|
||||
Neutron has an extension that allows CRUD operations on the ``/segments``
|
||||
|
|
|
@ -21,7 +21,7 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Services and agents
|
||||
Services and Agents
|
||||
===================
|
||||
|
||||
A usual Neutron setup consists of multiple services and agents running on one
|
||||
|
|
|
@ -21,8 +21,9 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
L2 Networking with SR-IOV enabled NICs
|
||||
======================================
|
||||
SR-IOV Networking L2 Agent
|
||||
==========================
|
||||
|
||||
SR-IOV (Single Root I/O Virtualization) is a specification that allows
|
||||
a PCIe device to appear to be multiple separate physical PCIe devices.
|
||||
SR-IOV works by introducing the idea of physical functions (PFs) and virtual functions (VFs).
|
||||
|
|
|
@ -21,8 +21,8 @@
|
|||
(Avoid deeper levels because they do not render well.)
|
||||
|
||||
|
||||
Add Tags to Neutron Resources
|
||||
=============================
|
||||
Tags in Neutron Resources
|
||||
=========================
|
||||
|
||||
Tag service plugin allows users to set tags on their resources. Tagging
|
||||
resources can be used by external systems or any other clients of the Neutron
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
..
|
||||
|
||||
================================================
|
||||
Deploying a development environment with vagrant
|
||||
================================================
|
||||
=====================================================
|
||||
Deploying an OVN Development Environment with vagrant
|
||||
=====================================================
|
||||
|
||||
|
||||
The vagrant directory contains a set of vagrant configurations which will
|
||||
help you deploy Neutron with ovn driver for testing or development purposes.
|
||||
help you deploy Neutron with the OVN driver for testing or development purposes.
|
||||
|
||||
We provide a sparse multinode architecture with clear separation between
|
||||
services. In the future we will include all-in-one and multi-gateway
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _neutron_bugs:
|
||||
|
||||
Neutron Bugs
|
||||
============
|
||||
Bugs
|
||||
====
|
||||
|
||||
Neutron (client, core, FwaaS, VPNaaS) maintains all of its bugs in the following
|
||||
Launchpad projects:
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _code_review:
|
||||
|
||||
Neutron Code Reviews
|
||||
====================
|
||||
Code Reviews
|
||||
============
|
||||
|
||||
Code reviews are a critical component of all OpenStack projects. Neutron accepts patches from many
|
||||
diverse people with diverse backgrounds, employers, and experience levels. Code reviews provide a
|
||||
|
|
|
@ -1,5 +1,6 @@
|
|||
Neutron Gate Failure Triage
|
||||
===========================
|
||||
|
||||
Gate Failure Triage
|
||||
===================
|
||||
|
||||
This page provides guidelines for spotting and assessing neutron gate failures. Some hints for triaging
|
||||
failures are also provided.
|
||||
|
|
|
@ -26,9 +26,9 @@ items.
|
|||
|
||||
blueprints
|
||||
bugs
|
||||
contributor-onboarding
|
||||
neutron-teams
|
||||
gate-failure-triage
|
||||
code-reviews
|
||||
contributor-onboarding
|
||||
gate-failure-triage
|
||||
release-checklist
|
||||
neutron-teams
|
||||
thirdparty-ci
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _neutron_teams:
|
||||
|
||||
======================
|
||||
Neutron Team Structure
|
||||
======================
|
||||
==============
|
||||
Team Structure
|
||||
==============
|
||||
|
||||
Neutron Core Reviewers
|
||||
======================
|
||||
|
|
|
@ -1,5 +1,6 @@
|
|||
Neutron Third-party CI
|
||||
======================
|
||||
|
||||
Third-party CI
|
||||
==============
|
||||
|
||||
What Is Expected of Third Party CI System for Neutron
|
||||
-----------------------------------------------------
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
|
||||
.. _ci_jobs:
|
||||
|
||||
Neutron jobs running in Zuul CI
|
||||
Neutron Jobs Running in Zuul CI
|
||||
===============================
|
||||
|
||||
Tempest jobs running in Neutron CI
|
||||
|
|
|
@ -32,10 +32,10 @@ Testing
|
|||
|
||||
testing
|
||||
fullstack
|
||||
coverage
|
||||
template_model_sync_test
|
||||
db_transient_failure_injection
|
||||
ml2_ovs_devstack
|
||||
ci_scenario_jobs
|
||||
ml2_ovn_devstack
|
||||
ml2_ovs_devstack
|
||||
tempest
|
||||
template_model_sync_test
|
||||
coverage
|
||||
db_transient_failure_injection
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _ml2_ovn_devstack:
|
||||
|
||||
=========================
|
||||
Testing OVN with DevStack
|
||||
=========================
|
||||
=================
|
||||
OVN with DevStack
|
||||
=================
|
||||
|
||||
This document describes how to test OpenStack with OVN using DevStack. We will
|
||||
start by describing how to test on a single host.
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. _ml2_ovs_devstack:
|
||||
|
||||
=============================
|
||||
Testing ML2 OVS with DevStack
|
||||
=============================
|
||||
=====================
|
||||
ML2 OVS with DevStack
|
||||
=====================
|
||||
|
||||
This document describes how to test OpenStack Neutron with ML2 OpenvSwitch using
|
||||
DevStack. We will start by describing how to test on a single host.
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
|
||||
.. _tempest_testing:
|
||||
|
||||
Tempest testing
|
||||
Tempest Testing
|
||||
===============
|
||||
|
||||
Tempest basics in Networking projects
|
||||
|
|
Loading…
Reference in New Issue