de38f2767f
Training labs parser will allow us to automatically parse RST code
to BASH. This BASH code in turn will be invoked by install-guides for
validating the install guides. To provide the correct information to the
parser for generating BASH code, there are a few changes required to the
RST syntax.
Introduces the following changes to RST syntax:
- `.. end`
This tag provides information for the parser to stop extracting the
given block which could be code, file injection or configuration
file edit.
- `.. endonly`
This tag provides information for the parser with the correct
distro-switch logic for identifying distro-specific code.
For .. only:: tags, it is better to avoid nesting. If nesting
is not avoidable then it is preferable to add the .. endonly
tag to close the outer block immediately.
- Extra new lines in code-blocks
Some commands in the code-blocks provides the expected output of the
given command. This is not a BASH command which we want to run but
rather some visual niceness for the users. These new lines provides
the parser information to identify the end of the command. This
basic logic would be something similar to find '\r\n' which at least
for python means new empty line.
- `mysql>`
Introducing this operator for mysql commands. This could potentially
be changed to `pgsql>` or similar for other SQL type databases.
This allows the parser to identify mysql commands and then run
them in mysql instead of in 'sh' or 'bash'.
- `.. path`
Introducing this tag to provide the parser with the information with
the path of the configuration file. Using the description text for
the same is not reliable since the description text may not be
consistent.
This commit should ideally introduce all the syntax changes required for
the parser to convert the code-blocks in here to BASH code. These
changes should have no impact on the HTML output of the RST code.
Change-Id: I47830b1bc61c8b1a0f3350932d15aa3ce88fa672
138 lines
5.7 KiB
ReStructuredText
138 lines
5.7 KiB
ReStructuredText
.. _environment-networking:
|
|
|
|
Host networking
|
|
~~~~~~~~~~~~~~~
|
|
|
|
.. only:: ubuntu
|
|
|
|
After installing the operating system on each node for the architecture
|
|
that you choose to deploy, you must configure the network interfaces. We
|
|
recommend that you disable any automated network management tools and
|
|
manually edit the appropriate configuration files for your distribution.
|
|
For more information on how to configure networking on your
|
|
distribution, see the `documentation <https://help.ubuntu.com/lts/serverguide/network-configuration.html>`__ .
|
|
|
|
.. endonly
|
|
|
|
.. only:: debian
|
|
|
|
After installing the operating system on each node for the architecture
|
|
that you choose to deploy, you must configure the network interfaces. We
|
|
recommend that you disable any automated network management tools and
|
|
manually edit the appropriate configuration files for your distribution.
|
|
For more information on how to configure networking on your
|
|
distribution, see the `documentation <https://wiki.debian.org/NetworkConfiguration>`__ .
|
|
|
|
.. endonly
|
|
|
|
.. only:: rdo
|
|
|
|
After installing the operating system on each node for the architecture
|
|
that you choose to deploy, you must configure the network interfaces. We
|
|
recommend that you disable any automated network management tools and
|
|
manually edit the appropriate configuration files for your distribution.
|
|
For more information on how to configure networking on your
|
|
distribution, see the `documentation <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Using_the_Command_Line_Interface.html>`__ .
|
|
|
|
.. endonly
|
|
|
|
.. only:: obs
|
|
|
|
After installing the operating system on each node for the architecture
|
|
that you choose to deploy, you must configure the network interfaces. We
|
|
recommend that you disable any automated network management tools and
|
|
manually edit the appropriate configuration files for your distribution.
|
|
For more information on how to configure networking on your
|
|
distribution, see the `SLES 12 <https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_basicnet_manconf.html>`__ or `openSUSE <http://activedoc.opensuse.org/book/opensuse-reference/chapter-13-basic-networking>`__ documentation.
|
|
|
|
.. endonly
|
|
|
|
All nodes require Internet access for administrative purposes such as package
|
|
installation, security updates, :term:`DNS <Domain Name System (DNS)>`, and
|
|
:term:`NTP <Network Time Protocol (NTP)>`. In most cases, nodes should obtain
|
|
internet access through the management network interface.
|
|
To highlight the importance of network separation, the example architectures
|
|
use `private address space <https://tools.ietf.org/html/rfc1918>`__ for the
|
|
management network and assume that the physical network infrastructure
|
|
provides Internet access via :term:`NAT <Network Address Translation (NAT)>`
|
|
or other method. The example architectures use routable IP address space for
|
|
the provider (external) network and assume that the physical network
|
|
infrastructure provides direct Internet access.
|
|
|
|
In the provider networks architecture, all instances attach directly
|
|
to the provider network. In the self-service (private) networks architecture,
|
|
instances can attach to a self-service or provider network. Self-service
|
|
networks can reside entirely within OpenStack or provide some level of external
|
|
network access using :term:`NAT <Network Address Translation (NAT)>` through
|
|
the provider network.
|
|
|
|
.. _figure-networklayout:
|
|
|
|
.. figure:: figures/networklayout.png
|
|
:alt: Network layout
|
|
|
|
The example architectures assume use of the following networks:
|
|
|
|
* Management on 10.0.0.0/24 with gateway 10.0.0.1
|
|
|
|
This network requires a gateway to provide Internet access to all
|
|
nodes for administrative purposes such as package installation,
|
|
security updates, :term:`DNS <Domain Name System (DNS)>`, and
|
|
:term:`NTP <Network Time Protocol (NTP)>`.
|
|
|
|
* Provider on 203.0.113.0/24 with gateway 203.0.113.1
|
|
|
|
This network requires a gateway to provide Internet access to
|
|
instances in your OpenStack environment.
|
|
|
|
You can modify these ranges and gateways to work with your particular
|
|
network infrastructure.
|
|
|
|
Network interface names vary by distribution. Traditionally,
|
|
interfaces use "eth" followed by a sequential number. To cover all
|
|
variations, this guide simply refers to the first interface as the
|
|
interface with the lowest number and the second interface as the
|
|
interface with the highest number.
|
|
|
|
Unless you intend to use the exact configuration provided in this
|
|
example architecture, you must modify the networks in this procedure to
|
|
match your environment. Also, each node must resolve the other nodes by
|
|
name in addition to IP address. For example, the ``controller`` name must
|
|
resolve to ``10.0.0.11``, the IP address of the management interface on
|
|
the controller node.
|
|
|
|
.. warning::
|
|
|
|
Reconfiguring network interfaces will interrupt network
|
|
connectivity. We recommend using a local terminal session for these
|
|
procedures.
|
|
|
|
.. note::
|
|
|
|
.. only:: rdo or obs
|
|
|
|
Your distribution enables a restrictive :term:`firewall` by
|
|
default. During the installation process, certain steps will
|
|
fail unless you alter or disable the firewall. For more
|
|
information about securing your environment, refer to the
|
|
`OpenStack Security Guide <http://docs.openstack.org/sec/>`__.
|
|
|
|
.. endonly
|
|
|
|
.. only:: ubuntu or debian
|
|
|
|
Your distribution does not enable a restrictive :term:`firewall`
|
|
by default. For more information about securing your environment,
|
|
refer to the
|
|
`OpenStack Security Guide <http://docs.openstack.org/sec/>`__.
|
|
|
|
.. endonly
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
environment-networking-controller.rst
|
|
environment-networking-compute.rst
|
|
environment-networking-storage-cinder.rst
|
|
environment-networking-verify.rst
|