openstack/kayobe
Code Issues Proposed changes

docs: Add initial all-in-one scenario

Browse Source 
This change adds a new 'scenarios' section to the configuration
documentation, with an initial 'all in one' scenario.

Change-Id: Ibe9cbbb59e2f72b18fdeb493feb085735edbbf8c
Story: 2004360
Task: 27960
This commit is contained in:
Mark Goddard 2020-08-28 08:40:17 +01:00
parent 7c25fec6ca
commit fd6ee4114b
4 changed files with 354 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/source/configuration/index.rst
View File

@ -2,7 +2,13 @@
Configuration Guide Configuration Guide
=================== ===================
The configuration guide is split into two parts - scenarios and reference.
The scenarios section provides information on configuring Kayobe for different
scenarios. The reference section provides detailed information on many of
Kayobe's configuration options.
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 2
scenarios/index
reference/index reference/index

54
doc/source/configuration/scenarios/all-in-one/index.rst Normal file
View File

@ -0,0 +1,54 @@
===================
All in one scenario
===================
This scenario describes how to configure an all-in-one controller and compute
node using Kayobe.
Overview
========
An all in one environment consists of a single node that provides both control
and compute services. There is no seed host, and no provisioning of the
overcloud host. Customisation is minimal, in order to demonstrate the basic
required configuration in Kayobe::
+---------------------------+
| Overcloud host |
| |
| |
| +-------------+ |
| | | |
| | Containers | |
| | | |
| +-------------+ |
| |
| |
+---------+-------+---------+
| |
| NIC 1 |
| |
+---+---+
|
|
+-----------------+------------------+ Internet
Prerequisites
=============
This scenario requires:
* a basic understanding of Linux, networking and OpenStack
* a single CentOS 8 host (VM or bare metal)
* at least one network interface that has Internet access
* an IP subnet with a free IP address for the OpenStack API virtual IP, and a
range of free IP addresses for external network access
Contents
========
.. toctree::
:maxdepth: 2
overcloud

283
doc/source/configuration/scenarios/all-in-one/overcloud.rst Normal file
View File

@ -0,0 +1,283 @@
=========
Overcloud
=========
Installation
============
SSH to the overcloud machine, then follow the instructions in
:doc:`/installation` to set up an Ansible control host environment.
Typically this would be on a separate machine, but here we are keeping things
as simple as possible.
Configuration
=============
Clone the `kayobe-config <https://opendev.org/openstack/kayobe-config>`_
git repository, using the correct branch for the release you are deploying. In
this example we will use the ``master`` branch.
.. code-block:: console
cd <base path>/src
git clone https://opendev.org/openstack/kayobe-config -b master
cd kayobe-config
This repository is bare, and needs to be populated. The repository includes an
example inventory, which should be removed:
.. code-block:: console
git rm etc/kayobe/inventory/hosts.example
Create an Ansible inventory file and add the machine to it. In this example our
machine is called ``controller0``. Since this is an all-in-one environment, we
add the controller to the ``compute`` group, however normally dedicated
compute nodes would be used.
.. code-block:: yaml
:caption: ``etc/kayobe/inventory/hosts``
# This host acts as the configuration management Ansible control host. This must be
# localhost.
localhost ansible_connection=local
[controllers]
controller0
[compute:children]
controllers
The ``inventory`` directory also contains group variables for network interface
configuration. In this example we will assume that the machine has a single
network interface called ``eth0``. We will create a bridge called ``breth0``
and plug ``eth0`` into it. This allows us to move the host's IP address to the
bridge, and pass traffic through to an Open vSwitch bridge for Neutron. Replace
the network interface configuration for the ``controllers`` group with the
following, replacing ``eth0`` with an appropriate interface:
.. code-block:: yaml
:caption: ``etc/kayobe/inventory/group_vars/controllers/network-interfaces``
# Controller interface on all-in-one network.
aio_interface: breth0
# Interface eth0 is plugged into the all-in-one network bridge.
aio_bridge_ports:
- eth0
In this scenario a single network called ``aio`` is used. We must therefore set
the name of the default controller networks to ``aio``:
.. code-block:: yaml
:caption: ``etc/kayobe/networks.yml``
---
# Kayobe network configuration.
###############################################################################
# Network role to network mappings.
# Map all networks to the all-in-one network.
# Name of the network used for admin access to the overcloud
#admin_oc_net_name:
admin_oc_net_name: aio
# Name of the network used by the seed to manage the bare metal overcloud
# hosts via their out-of-band management controllers.
#oob_oc_net_name:
# Name of the network used by the seed to provision the bare metal overcloud
# hosts.
#provision_oc_net_name:
# Name of the network used by the overcloud hosts to manage the bare metal
# compute hosts via their out-of-band management controllers.
#oob_wl_net_name:
# Name of the network used by the overcloud hosts to provision the bare metal
# workload hosts.
#provision_wl_net_name:
# Name of the network used to expose the internal OpenStack API endpoints.
#internal_net_name:
internal_net_name: aio
# List of names of networks used to provide external network access via
# Neutron.
# Deprecated name: external_net_name
# If external_net_name is defined, external_net_names will default to a list
# containing one item, external_net_name.
#external_net_names:
external_net_names:
- aio
# Name of the network used to expose the public OpenStack API endpoints.
#public_net_name:
public_net_name: aio
# Name of the network used by Neutron to carry tenant overlay network traffic.
#tunnel_net_name:
tunnel_net_name: aio
# Name of the network used to carry storage data traffic.
#storage_net_name:
storage_net_name: aio
# Name of the network used to carry storage management traffic.
#storage_mgmt_net_name:
storage_mgmt_net_name: aio
# Name of the network used to carry swift storage data traffic.
#swift_storage_net_name:
# Name of the network used to carry swift storage replication traffic.
#swift_storage_replication_net_name:
# Name of the network used to perform hardware introspection on the bare metal
# workload hosts.
#inspection_net_name:
# Name of the network used to perform cleaning on the bare metal workload
# hosts
#cleaning_net_name:
###############################################################################
# Network definitions.
<omitted for clarity>
Next the ``aio`` network must be defined. This is done using the various
attributes described in :doc:`/configuration/reference/network`. These
values should be adjusted to match the environment. The ``aio_vip_address``
variable should be a free IP address in the same subnet for the virtual IP
address of the OpenStack API.
.. code-block:: yaml
:caption: ``etc/kayobe/networks.yml``
<omitted for clarity>
###############################################################################
# Network definitions.
# All-in-one network.
aio_cidr: 192.168.33.0/24
aio_gateway: 192.168.33.1
aio_vip_address: 192.168.33.2
###############################################################################
# Network virtual patch link configuration.
<omitted for clarity>
Kayobe will automatically allocate IP addresses. In this case however, we want
to ensure that the host uses the same IP address it has currently, to avoid
loss of connectivity. We can do this by populating the network allocation file.
Use the correct hostname and IP address for your environment.
.. code-block:: yaml
:caption: ``etc/kayobe/network-allocation.yml``
---
aio_ips:
controller0: 192.168.33.3
In a development environment, we may wish to tune some Kolla Ansible variables.
Using QEMU as the virtualisation type will be necessary if KVM is not
available. Reducing the number of OpenStack service workers helps to avoid
using too much memory.
.. code-block:: yaml
:caption: ``etc/kayobe/kolla/globals.yml``
---
# Most development environments will use nested virtualisation, and we can't
# guarantee that nested KVM support is available. Use QEMU as a lowest common
# denominator.
nova_compute_virt_type: qemu
# Reduce the control plane's memory footprint by limiting the number of worker
# processes to one per-service.
openstack_service_workers: "1"
Activate the Kayobe configuration environment:
.. code-block:: console
source kayobe-env
Bootstrap the control host:
.. code-block:: console
kayobe control host bootstrap
Configure the overcloud host:
.. code-block:: console
kayobe overcloud host configure
The previous command is likely to reboot the machine to disable SELinux. SSH
again when it has booted, activate the Kayobe environment and complete the host
configuration:
.. code-block:: console
kayobe overcloud host configure
Pull overcloud container images:
.. code-block:: console
kayobe overcloud container image pull
Deploy overcloud services:
.. code-block:: console
kayobe overcloud service deploy
There is an issue with Docker where it changes the default policy of the
``FORWARD`` chain to ``DROP``. This prevents traffic traversing the bridge.
Revert this change:
.. code-block:: console
sudo iptables -P FORWARD ACCEPT
The ``init-runonce`` script provided by Kolla Ansible (not for production) can
be used to setup some resources for testing. This includes:
* some flavors
* a `cirros <https://download.cirros-cloud.net/>`_ image
* an external network
* a tenant network and router
* security group rules for ICMP, SSH, and TCP ports 8000 and 8080
* an SSH key
* increased quotas
For the external network, use the same subnet as before, with an allocation
pool range containing free IP addresses:
.. code-block:: console
pip install python-openstackclient
export EXT_NET_CIDR=192.168.33.0/24
export EXT_NET_GATEWAY=192.168.33.1
export EXT_NET_RANGE="start=192.168.33.4,end=192.168.33.254"
source "${KOLLA_CONFIG_PATH:-/etc/kolla}/admin-openrc.sh"
${KOLLA_SOURCE_PATH}/tools/init-runonce
Create a server instance, assign a floating IP address, and check that it is
accessible. The floating IP address is displayed after it is created, in this
example it is ``192.168.33.4``:
.. code-block:: console
openstack server create --image cirros --flavor m1.tiny --key-name mykey --network demo-net demo1
openstack floating ip create public1
openstack server add floating ip demo1 192.168.33.4
ssh cirros@192.168.33.4

11
doc/source/configuration/scenarios/index.rst Normal file
View File

@ -0,0 +1,11 @@
=======================
Configuration Scenarios
=======================
This section provides information on configuring Kayobe for different
scenarios.
.. toctree::
:maxdepth: 2
all-in-one/index