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
3.0 KiB
Environment
This section explains how to configure the controller node and one compute node using the example architecture.
Although most environments include Identity, Image service, Compute, at least one networking service, and the Dashboard, the Object Storage service can operate independently. If your use case only involves Object Storage, you can skip to Object Storage Installation Guide after configuring the appropriate nodes for it.
You must use an account with administrative privileges to configure
each node. Either run the commands as the root user or
configure the sudo utility.
obs
The systemctl enable call on openSUSE outputs a
warning message when the service uses SysV Init scripts instead of
native systemd files. This warning can be ignored.
For best performance, we recommend that your environment meets or
exceeds the hardware requirements in figure-hwreqs.
The following minimum requirements should support a proof-of-concept
environment with core services and several CirrOS instances:
- Controller Node: 1 processor, 4 GB memory, and 5 GB storage
- Compute Node: 1 processor, 2 GB memory, and 10 GB storage
As the number of OpenStack services and virtual machines increase, so do the hardware requirements for the best performance. If performance degrades after enabling additional services or virtual machines, consider adding hardware resources to your environment.
To minimize clutter and provide more resources for OpenStack, we recommend a minimal installation of your Linux distribution. Also, you must install a 64-bit version of your distribution on each node.
A single disk partition on each node works for most basic
installations. However, you should consider Logical Volume Manager (LVM)
for installations with optional services such as Block Storage.
For first-time installation and testing purposes, many users select
to build each host as a virtual machine (VM). The primary benefits of VMs
include the following:
- One physical server can support multiple nodes, each with almost any number of network interfaces.
- Ability to take periodic "snap shots" throughout the installation process and "roll back" to a working configuration in the event of a problem.
However, VMs will reduce performance of your instances, particularly if your hypervisor and/or processor lacks support for hardware acceleration of nested VMs.
Note
If you choose to install on VMs, make sure your hypervisor provides a way to disable MAC address filtering on the provider network interface.
For more information about system requirements, see the OpenStack Operations Guide.
environment-security.rst environment-networking.rst environment-ntp.rst environment-packages.rst environment-sql-database.rst environment-messaging.rst environment-memcached.rst