Alphabetize some of the admin and contrib docs
Over time docs were added or updated such that they were no longer in alphabetical order based on the index order or their title strings. Tried to fix it up a bit along with some capitalization. Trivialfix Change-Id: I948b2a1c86faaffed07adcf0198a3fba72401abe
This commit is contained in:
Brian Haley
parent
741f504c7b
commit
e63cdd216b
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -53,6 +53,7 @@ Neutron Internals
|
|||
objects_usage
|
||||
openvswitch_agent
|
||||
openvswitch_firewall
|
||||
ovn/index
|
||||
ovs_vhostuser
|
||||
plugin-api
|
||||
policy
|
||||
|
|
@ -69,4 +70,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