Pranav Salunke de38f2767f install: Updates syntax for training labs parser.

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

2016-09-28 10:58:06 +02:00

5.7 KiB

Raw Blame History

Host networking

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 .

debian

rdo

obs

All nodes require Internet access for administrative purposes such as package installation, security updates, DNS <Domain Name System (DNS)>, and 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 for the management network and assume that the physical network infrastructure provides Internet access via 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 NAT <Network Address Translation (NAT)> through the provider network.

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, DNS <Domain Name System (DNS)>, and 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

rdo or obs

Your distribution enables a restrictive 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.

ubuntu or debian

Your distribution does not enable a restrictive firewall by default. For more information about securing your environment, refer to the OpenStack Security Guide.

environment-networking-controller.rst environment-networking-compute.rst environment-networking-storage-cinder.rst environment-networking-verify.rst

5.7 KiB Raw Blame History

Host networking

5.7 KiB

Raw Blame History