openstack/neutron
Code Issues Proposed changes

Merge "Update the documentation links"

Browse Source
This commit is contained in:
Zuul 2017-12-13 22:48:29 +00:00 committed by Gerrit Code Review
commit dd04c80307
10 changed files with 23 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/source/admin/config-auto-allocation.rst
View File

@ -51,8 +51,7 @@ topology creation. To perform this task, proceed with the following steps:
#. Set up a default external network #. Set up a default external network
Setting up an external network is described in Setting up an external network is described in
`OpenStack Administrator Guide `OpenStack Networking Guide <./archives/adv-features.html>`_.
<https://docs.openstack.org/admin-guide/networking-adv-features.html>`_.
Assuming the external network to be used for the auto-allocation feature Assuming the external network to be used for the auto-allocation feature
is named ``public``, make it the ``default`` external network is named ``public``, make it the ``default`` external network
with the following command: with the following command:

8
doc/source/admin/config-lbaas.rst
View File

@ -20,14 +20,6 @@ separate worker processes that build load balancers within virtual machines on
hypervisors that are managed by the Compute service. You do not need an agent hypervisors that are managed by the Compute service. You do not need an agent
for Octavia. for Octavia.
.. note::
LBaaS v1 was removed in the Newton release. These links provide more
details about how LBaaS v1 works and how to configure it:
* `Load-Balancer-as-a-Service (LBaaS) overview <https://docs.openstack.org/admin-guide/networking-introduction.html#load-balancer-as-a-service-lbaas-overview>`__
* `Basic Load-Balancer-as-a-Service operations <https://docs.openstack.org/admin-guide/networking-adv-features.html#basic-load-balancer-as-a-service-operations>`__
.. warning:: .. warning::
Currently, no migration path exists between v1 and v2 load balancers. If you Currently, no migration path exists between v1 and v2 load balancers. If you

2
doc/source/admin/config-ovs-dpdk.rst
View File

@ -84,7 +84,7 @@ For example:
$ openstack flavor set m1.large --property hw:mem_page_size=large $ openstack flavor set m1.large --property hw:mem_page_size=large
For more information about the syntax for ``hw:mem_page_size``, refer to the For more information about the syntax for ``hw:mem_page_size``, refer to the
`Flavors <https://docs.openstack.org/admin-guide/compute-flavors.html>`__ guide. `Flavors <https://docs.openstack.org/nova/latest/admin/flavors.html>`__ guide.
.. note:: .. note::

2
doc/source/admin/config-sriov.rst
View File

@ -409,7 +409,7 @@ Once configuration is complete, you can launch instances with SR-IOV ports.
There are two ways to attach VFs to an instance. You can create an SR-IOV There are two ways to attach VFs to an instance. You can create an SR-IOV
port or use the ``pci_alias`` in the Compute service. For more port or use the ``pci_alias`` in the Compute service. For more
information about using ``pci_alias``, refer to `nova-api configuration information about using ``pci_alias``, refer to `nova-api configuration
<https://docs.openstack.org/admin-guide/compute-pci-passthrough.html#configure-nova-api-controller>`__. <https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure-nova-api-controller>`__.
SR-IOV with InfiniBand SR-IOV with InfiniBand
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~

4
doc/source/admin/intro-basic-networking.rst
View File

@ -412,8 +412,8 @@ for many TCP-based services, as well as services that use other layer 4
protocols that employ ports. Registering a TCP port number is not required, but protocols that employ ports. Registering a TCP port number is not required, but
registering a port number is helpful to avoid collisions with other registering a port number is helpful to avoid collisions with other
services. See `firewalls and default ports services. See `firewalls and default ports
<https://docs.openstack.org/admin-guide/firewalls-default-ports.html>`_ <https://docs.openstack.org/install-guide/firewalls-default-ports.html>`_
in OpenStack Administrator Guide for the default TCP ports used by in OpenStack Installation Guide for the default TCP ports used by
various services involved in an OpenStack deployment. various services involved in an OpenStack deployment.

22
doc/source/contributor/internals/layer3.rst
View File

@ -132,7 +132,7 @@ Neutron logical router setup
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+--------+ +--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+--------+
See the `Networking Guide <http://docs.openstack.org/networking-guide/deploy-ovs-selfservice.html#create-initial-networks/>`_ See the `Networking Guide <../../admin/deploy-ovs-selfservice.html#create-initial-networks>`_
for more detail on the creation of networks, subnets, and routers. for more detail on the creation of networks, subnets, and routers.
Neutron Routers are realized in OpenVSwitch Neutron Routers are realized in OpenVSwitch
@ -202,16 +202,14 @@ Neutron Routers are realized in OpenVSwitch
Finding the router in ip/ipconfig Finding the router in ip/ipconfig
--------------------------------- ---------------------------------
* http://docs.openstack.org/admin-guide/networking.html The neutron-l3-agent uses the Linux IP stack and iptables to perform L3 forwarding and NAT.
In order to support multiple routers with potentially overlapping IP addresses, neutron-l3-agent
defaults to using Linux network namespaces to provide isolated forwarding contexts. As a result,
the IP addresses of routers will not be visible simply by running "ip addr list" or "ifconfig" on
the node. Similarly, you will not be able to directly ping fixed IPs.
The neutron-l3-agent uses the Linux IP stack and iptables to perform L3 forwarding and NAT. To do either of these things, you must run the command within a particular router's network
In order to support multiple routers with potentially overlapping IP addresses, neutron-l3-agent namespace. The namespace will have the name "qrouter-<UUID of the router>.
defaults to using Linux network namespaces to provide isolated forwarding contexts. As a result,
the IP addresses of routers will not be visible simply by running "ip addr list" or "ifconfig" on
the node. Similarly, you will not be able to directly ping fixed IPs.
To do either of these things, you must run the command within a particular router's network
namespace. The namespace will have the name "qrouter-<UUID of the router>.
.. image:: images/under-the-hood-scenario-1-ovs-netns.png .. image:: images/under-the-hood-scenario-1-ovs-netns.png
@ -244,7 +242,7 @@ For example::
Provider Networking Provider Networking
------------------- -------------------
Neutron can also be configured to create `provider networks <http://docs.openstack.org/admin-guide/networking_adv-features.html#provider-networks>`_ Neutron can also be configured to create `provider networks <../../admin/archives/adv-features.html#provider-networks>`_.
.. include:: l3_agent_extensions.rst .. include:: l3_agent_extensions.rst
@ -252,6 +250,6 @@ Further Reading
--------------- ---------------
* `Packet Pushers - Neutron Network Implementation on Linux <http://packetpushers.net/openstack-quantum-network-implementation-in-linux/>`_ * `Packet Pushers - Neutron Network Implementation on Linux <http://packetpushers.net/openstack-quantum-network-implementation-in-linux/>`_
* `OpenStack Administrator Guide <http://docs.openstack.org/admin-guide/networking.html>`_ * `OpenStack Networking Guide <../../admin/index.html>`_
* `Neutron - Layer 3 API extension <https://developer.openstack.org/api-ref/networking/v2/index.html#layer-3-networking>`_ * `Neutron - Layer 3 API extension <https://developer.openstack.org/api-ref/networking/v2/index.html#layer-3-networking>`_
* `Darragh O'Reilly - The Quantum L3 router and floating IPs <http://techbackground.blogspot.com/2013/05/the-quantum-l3-router-and-floating-ips.html>`_ * `Darragh O'Reilly - The Quantum L3 router and floating IPs <http://techbackground.blogspot.com/2013/05/the-quantum-l3-router-and-floating-ips.html>`_

12
doc/source/contributor/internals/linuxbridge_agent.rst
View File

@ -28,8 +28,7 @@ This Agent uses the `Linux Bridge
<http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge>`_ to <http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge>`_ to
provide L2 connectivity for VM instances running on the compute node to the provide L2 connectivity for VM instances running on the compute node to the
public network. A graphical illustration of the deployment can be found in public network. A graphical illustration of the deployment can be found in
`Networking Guide `Networking Guide <../../admin/deploy-lb-provider.html#architecture>`_.
<http://docs.openstack.org/networking-guide/deploy-lb-provider.html#architecture>`_
In most common deployments, there is a compute and a network node. On both the In most common deployments, there is a compute and a network node. On both the
compute and the network node, the Linux Bridge Agent will manage virtual compute and the network node, the Linux Bridge Agent will manage virtual
@ -39,11 +38,8 @@ on the compute node, the Linux Bridge Agent will manage security groups.
Three use cases and their packet flow are documented as follows: Three use cases and their packet flow are documented as follows:
1. `Linux Bridge: Provider networks 1. `Linux Bridge: Provider networks <../../admin/deploy-lb-provider.html>`_
<http://docs.openstack.org/networking-guide/deploy-lb-provider.html>`_
2. `Linux Bridge: Self-service networks 2. `Linux Bridge: Self-service networks <../../admin/deploy-lb-selfservice.html>`_
<http://docs.openstack.org/networking-guide/deploy-lb-selfservice.html>`_
3. `Linux Bridge: High availability using VRRP 3. `Linux Bridge: High availability using VRRP <../../admin/deploy-lb-ha-vrrp.html>`_
<http://docs.openstack.org/networking-guide/deploy-lb-ha-vrrp.html>`_

4
doc/source/feature_classification/general_feature_support_matrix.ini
View File

@ -164,7 +164,7 @@ title=DNS
status=mature status=mature
api=dns-integration api=dns-integration
notes=The ability to integrate with an external DNS notes=The ability to integrate with an external DNS
as a Service. http://docs.openstack.org/pike/networking-guide/config-dns-int.html as a Service. https://docs.openstack.org/neutron/latest/admin/config-dns-int.html
networking-ovs=complete networking-ovs=complete
networking-linux-bridge=complete networking-linux-bridge=complete
networking-odl=complete networking-odl=complete
@ -200,7 +200,7 @@ networking-ovn=unknown
title=Routed Provider Networks title=Routed Provider Networks
status=immature status=immature
notes=The ability to present a multi-segment layer-3 network as a notes=The ability to present a multi-segment layer-3 network as a
single entity. https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html single entity. https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html
networking-ovs=partial networking-ovs=partial
networking-linux-bridge=partial networking-linux-bridge=partial
networking-odl=incomplete networking-odl=incomplete

2
doc/source/install/overview.rst
View File

@ -60,7 +60,7 @@ follows:
For more information on production architectures, see the For more information on production architectures, see the
`Architecture Design Guide <https://docs.openstack.org/arch-design/>`_, `Architecture Design Guide <https://docs.openstack.org/arch-design/>`_,
`OpenStack Operations Guide <https://docs.openstack.org/ops-guide/>`_, and `OpenStack Operations Guide <https://wiki.openstack.org/wiki/OpsGuide>`_, and
:doc:`OpenStack Networking Guide </admin/index>`. :doc:`OpenStack Networking Guide </admin/index>`.
.. _figure-hwreqs: .. _figure-hwreqs:

2
releasenotes/notes/add-availability-zone-4440cf00be7c54ba.yaml
View File

@ -10,4 +10,4 @@ features:
because L3HA and DVR integration isn't finished. because L3HA and DVR integration isn't finished.
other: other:
- Please read the `OpenStack Networking Guide - Please read the `OpenStack Networking Guide
<http://docs.openstack.org/mitaka/networking-guide/adv-config-availability-zone.html>`_. <https://docs.openstack.org/neutron/latest/admin/config-az.html>`_.