Update the documentation links

The documentation links which start with "admin-guide" and
"networking-guide" are outdated. Fix them to be friendly
to new contributors.

Change-Id: I656ba3b82df6acd2555735093127ca59f7042d44

doc/source/admin/config-auto-allocation.rst

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

doc/source/admin/config-lbaas.rst

@@ -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
 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::
 
    Currently, no migration path exists between v1 and v2 load balancers. If you

doc/source/admin/config-ovs-dpdk.rst

@@ -84,7 +84,7 @@ For example:
    $ 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
-`Flavors <https://docs.openstack.org/admin-guide/compute-flavors.html>`__ guide.
+`Flavors <https://docs.openstack.org/nova/latest/admin/flavors.html>`__ guide.
 
 .. note::
 

doc/source/admin/config-sriov.rst

@@ -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
       port or use the ``pci_alias`` in the Compute service. For more
       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
 ~~~~~~~~~~~~~~~~~~~~~~

doc/source/admin/intro-basic-networking.rst

@@ -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
 registering a port number is helpful to avoid collisions with other
 services. See `firewalls and default ports
-<https://docs.openstack.org/admin-guide/firewalls-default-ports.html>`_
-in OpenStack Administrator Guide for the default TCP ports used by
+<https://docs.openstack.org/install-guide/firewalls-default-ports.html>`_
+in OpenStack Installation Guide for the default TCP ports used by
 various services involved in an OpenStack deployment.
 
 

doc/source/contributor/internals/layer3.rst

@@ -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.
 
 Neutron Routers are realized in OpenVSwitch
@@ -202,16 +202,14 @@ Neutron Routers are realized in OpenVSwitch
 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.
-        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.
-
-        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>.
+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
 
@@ -244,7 +242,7 @@ For example::
 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
 
@@ -252,6 +250,6 @@ Further Reading
 ---------------
 
 * `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>`_
 * `Darragh O'Reilly -  The Quantum L3 router and floating IPs <http://techbackground.blogspot.com/2013/05/the-quantum-l3-router-and-floating-ips.html>`_

doc/source/contributor/internals/linuxbridge_agent.rst

@@ -28,8 +28,7 @@ This Agent uses the `Linux Bridge
 <http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge>`_ to
 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
-`Networking Guide
-<http://docs.openstack.org/networking-guide/deploy-lb-provider.html#architecture>`_
+`Networking Guide <../../admin/deploy-lb-provider.html#architecture>`_.
 
 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
@@ -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:
 
-1. `Linux Bridge: Provider networks
-   <http://docs.openstack.org/networking-guide/deploy-lb-provider.html>`_
+1. `Linux Bridge: Provider networks <../../admin/deploy-lb-provider.html>`_
 
-2. `Linux Bridge: Self-service networks
-   <http://docs.openstack.org/networking-guide/deploy-lb-selfservice.html>`_
+2. `Linux Bridge: Self-service networks <../../admin/deploy-lb-selfservice.html>`_
 
-3. `Linux Bridge: High availability using VRRP
-   <http://docs.openstack.org/networking-guide/deploy-lb-ha-vrrp.html>`_
+3. `Linux Bridge: High availability using VRRP <../../admin/deploy-lb-ha-vrrp.html>`_

doc/source/feature_classification/general_feature_support_matrix.ini

@@ -164,7 +164,7 @@ title=DNS
 status=mature
 api=dns-integration
 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-linux-bridge=complete
 networking-odl=complete
@@ -200,7 +200,7 @@ networking-ovn=unknown
 title=Routed Provider Networks
 status=immature
 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-linux-bridge=partial
 networking-odl=incomplete

doc/source/install/overview.rst

@@ -60,7 +60,7 @@ follows:
 
 For more information on production architectures, see the
 `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>`.
 
 .. _figure-hwreqs:

releasenotes/notes/add-availability-zone-4440cf00be7c54ba.yaml

@@ -10,4 +10,4 @@ features:
     because L3HA and DVR integration isn't finished.
 other:
   - 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>`_.