Skip to content
Snippets Groups Projects
Select Git revision
  • deployment default
1 result
Blame Permalink
  • Mark Goddard's avatar
    1dce9909
    Remove unsupported kolla_docker_registry_insecure variable · 1dce9909
    Mark Goddard authored 
    This variable is not supported since
I61a61ca59652b13687c2247d5881012b51f666a7, but was not removed from
etc/kayobe/kolla.yml in that change.

This change also adds the replacement variable docker_registry_insecure
to etc/kayobe/docker.yml.

TrivialFix
Change-Id: I3fa96f0276e08a6678e5d743399d01bc19a8dd1b
    1dce9909
    History
    Remove unsupported kolla_docker_registry_insecure variable
    Mark Goddard authored 
    This variable is not supported since
I61a61ca59652b13687c2247d5881012b51f666a7, but was not removed from
etc/kayobe/kolla.yml in that change.

This change also adds the replacement variable docker_registry_insecure
to etc/kayobe/docker.yml.

TrivialFix
Change-Id: I3fa96f0276e08a6678e5d743399d01bc19a8dd1b
hosts.rst 42.86 KiB

Host Configuration

This section covers configuration of hosts. It does not cover configuration or deployment of containers. Hosts that are configured by Kayobe include:

  • Seed hypervisor (kayobe seed hypervisor host configure)
  • Seed (kayobe seed host configure)
  • Infra VMs (kayobe infra vm host configure)
  • Overcloud (kayobe overcloud host configure)

Unless otherwise stated, all host configuration described here is applied to each of these types of host.

Configuration Location

Some host configuration options are set via global variables, and others have a variable for each type of host. The latter variables are included in the following files under ${KAYOBE_CONFIG_PATH}:

  • seed-hypervisor.yml
  • seed.yml
  • compute.yml
  • controller.yml
  • infra-vms.yml
  • monitoring.yml
  • storage.yml

Note that any variable may be set on a per-host or per-group basis, by using inventory host or group variables - these delineations are for convenience.

Paths

Several directories are used by Kayobe on the remote hosts. There is a hierarchy of variables in ${KAYOBE_CONFIG_PATH}/globals.yml that can be used to control where these are located.

  • base_path (default /opt/kayobe/) sets the default base path for various directories.
  • config_path (default {{ base_path }}/etc) is a path in which to store configuration files.
  • image_cache_path (default {{ base_path }}/images) is a path in which to cache downloaded or built images.
  • source_checkout_path (default {{ base_path }}/src) is a path into which to store clones of source code repositories.
  • virtualenv_path (default {{ base_path }}/venvs) is a path in which to create Python virtual environments.

SSH Known Hosts

tags:
ssh-known-host

While strictly this configuration is applied to the Ansible control host (localhost), it is applied during the host configure commands. The ansible_host of each host is added as an SSH known host. This is typically the host's IP address on the admin network (admin_oc_net_name), as defined in ${KAYOBE_CONFIG_PATH}/network-allocation.yml (see :ref:`configuration-network-ip-allocation`).

Kayobe User Bootstrapping

tags:
kayobe-ansible-user

Kayobe uses a user account defined by the kayobe_ansible_user variable (in ${KAYOBE_CONFIG_PATH}/globals.yml) for remote SSH access. By default, this is stack.

Typically, the image used to provision these hosts will not include this user account, so Kayobe performs a bootstrapping step to create it, as a different user. In cloud images, there is often a user named after the OS distro, e.g. centos, rocky or ubuntu. This user defaults to the os_distribution variable, but may be set via the following variables:

  • seed_hypervisor_bootstrap_user
  • seed_bootstrap_user
  • infra_vm_bootstrap_user
  • compute_bootstrap_user
  • controller_bootstrap_user
  • monitoring_bootstrap_user
  • storage_bootstrap_user

For example, to set the bootstrap user for controllers to example-user:

PyPI Mirror and proxy

tags:
pip

Kayobe supports configuration of a PyPI mirror and/or proxy, via variables in ${KAYOBE_CONFIG_PATH}/pip.yml. Mirror functionality is enabled by setting the pip_local_mirror variable to true and proxy functionality is enabled by setting pip_proxy variable to a proxy URL.

Kayobe will generate configuration for:

  • pip to use the mirror and proxy
  • easy_install to use the mirror

for the list of users defined by pip_applicable_users (default kayobe_ansible_user and root), in addition to the user used for Kolla Ansible (kolla_ansible_user). The mirror URL is configured via pip_index_url, and pip_trusted_hosts is a list of 'trusted' hosts, for which SSL verification will be disabled.

For example, to configure use of the test PyPI mirror at https://test.pypi.org/simple/:

To configure use of the PyPI proxy:

Kayobe Remote Virtual Environment

tags:
kayobe-target-venv

By default, Ansible executes modules remotely using the system python interpreter, even if the Ansible control process is executed from within a virtual environment (unless the local connection plugin is used). This is not ideal if there are python dependencies that must be installed with isolation from the system python packages. Ansible can be configured to use a virtualenv by setting the host variable ansible_python_interpreter to a path to a python interpreter in an existing virtual environment.

If kayobe detects that ansible_python_interpreter is set and references a virtual environment, it will create the virtual environment if it does not exist. Typically this variable should be set via a group variable in the inventory for hosts in the seed, seed-hypervisor, and/or overcloud groups.

The default Kayobe configuration in the kayobe-config repository sets ansible_python_interpreter to {{ virtualenv_path }}/kayobe/bin/python for the seed, seed-hypervisor, and overcloud groups.

Disk Wiping

tags:
wipe-disks

Using hosts that may have stale data on their disks could affect the deployment of the cloud. This is not a configuration option, since it should only be performed once to avoid losing useful data. It is triggered by passing the --wipe-disks argument to the host configure commands.

Users and Groups

tags:
users

Linux user accounts and groups can be configured using the users_default variable in ${KAYOBE_CONFIG_PATH}/users.yml. The format of the list is that used by the users variable of the singleplatform-eng.users role. The following variables can be used to set the users for specific types of hosts:

  • seed_hypervisor_users
  • seed_users
  • infra_vm_users
  • compute_users
  • controller_users
  • monitoring_users
  • storage_users

In the following example, a single user named bob is created. A password hash has been generated via mkpasswd --method=sha-512. The user is added to the wheel group, and an SSH key is authorised. The SSH public key should be added to the Kayobe configuration.

DNF Package Repositories

tags:
dnf

On CentOS and Rocky, Kayobe supports configuration of package repositories via DNF, via variables in ${KAYOBE_CONFIG_PATH}/dnf.yml.

Configuration of dnf.conf

Global configuration of DNF is stored in /etc/dnf/dnf.conf, and options can be set via the dnf_config variable. Options are added to the [main] section of the file. For example, to configure DNF to use a proxy server:

CentOS/Rocky and EPEL Mirrors

CentOS/Rocky and EPEL mirrors can be enabled by setting dnf_use_local_mirror to true. CentOS repository mirrors are configured via the following variables:

  • dnf_centos_mirror_host (default mirror.centos.org) is the mirror hostname.
  • dnf_centos_mirror_directory (default centos) is a directory on the mirror in which repositories may be accessed.

Rocky repository mirrors are configured via the following variables:

  • dnf_rocky_mirror_host (default dl.rockylinux.org) is the mirror hostname
  • dnf_rocky_mirror_directory (default pub/rocky) is a directory on the mirror in which repositories may be accessed.

EPEL repository mirrors are configured via the following variables:

  • dnf_epel_mirror_host (default download.fedoraproject.org) is the mirror hostname.
  • dnf_epel_mirror_directory (default pub/epel) is a directory on the mirror in which repositories may be accessed.

For example, to configure CentOS and EPEL mirrors at mirror.example.com:

Custom DNF Repositories

It is also possible to configure a list of custom DNF repositories via the dnf_custom_repos variable. The format is a dict/map, with repository names mapping to a dict/map of arguments to pass to the Ansible yum_repository module.

For example, the following configuration defines a single DNF repository called widgets.