diff options
Diffstat (limited to 'doc')
41 files changed, 404 insertions, 187 deletions
diff --git a/doc/source/admin/acme.rst b/doc/source/admin/acme.rst index 6a12efe11..2955c9f3a 100644 --- a/doc/source/admin/acme.rst +++ b/doc/source/admin/acme.rst @@ -26,7 +26,7 @@ is ``192.168.1.1``, the config would look like the following: .. code-block:: yaml - enable_horizon: "yes" + enable_horizon: true acme_client_servers: - server certbot 192.168.1.1:80 diff --git a/doc/source/admin/advanced-configuration.rst b/doc/source/admin/advanced-configuration.rst index 579dd11ca..c85a498dc 100644 --- a/doc/source/admin/advanced-configuration.rst +++ b/doc/source/admin/advanced-configuration.rst @@ -178,6 +178,113 @@ operator needs to create ``/etc/kolla/config/global.conf`` with content: [database] max_pool_size = 100 +Large baremetal deployments +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Out of the box, a typical Kolla Ansible deployment can support managing a few +hundred baremetal nodes. Beyond this number, it becomes necessary to configure +scaling mechanisms built into Nova and Ironic. + +There are two mechanisms to consider: + - shards + - conductor groups + +Please see the Ironic documentation for further `information +<https://docs.openstack.org/ironic/latest/admin/availability-zones.html#common-deployment-patterns>`_. + +As an example, consider a deployment of 700 baremetal nodes spread over two +distinct locations. Location 1 consists of 500 baremetal nodes, and location 2 +consists of 200 baremetal nodes. + +For location 1, all 500 nodes are placed into the same Ironic conductor +group. Ironic conductors configured to use this group are deployed on each +of the three nodes in the control plane. A single Nova Compute Ironic service +would struggle to manage this many nodes, so two shards are created. Due to +HA limitations with Nova Compute Ironic, a single instance is created for +each shard, and the instances may be deployed to any node in the control +plane. + +For location 2, no shards are required due to the smaller number of baremetal +nodes. A single conductor group is configured. The result is that three Ironic +conductors are deployed (one on each node in the control plane), and a single +instance of Nova Compute Ironic configured to use this conductor group. +Furthermore, for this location ``custom_host`` is used to override the +automatically generated host field in the configuration. This is useful for +migrating to the multi-instance configuration described here. + +Finally, Ironic and Nova services are deployed with no configured shards or +conductor groups as a catch all. + +.. code-block:: yaml + + nova_multi_compute_ironic_config: + - "shard_key": "shard_1" + "conductor_group": "location_1" + - "shard_key": "shard_2" + "conductor_group": "location_1" + - "conductor_group": "location_2" + "custom_host": "some_custom_host_field" + - {} + +.. note:: + + ``nova_multi_compute_ironic_config`` must be defined as a global variable + and not customised via hostvars. + +.. note:: + + If you currently have the ``nova-compute-ironic`` service deployed, + you must manually remove it from the controllers before migrating to the + new mode. You will need to ensure that you configure a compatible service + in ``nova_multi_compute_ironic_config`` to replace the old one. This will + likely involve setting the ``custom_host`` field at the very minimum. + +The placement of the above services is managed via the inventory. This +allows flexible placement, should a controller fail. + +.. code-block:: yaml + + [nova-compute-ironic-1] + controller-01 + [nova-compute-ironic-2] + controller-02 + [nova-compute-ironic-3] + controller-03 + [nova-compute-ironic-4] + controller-03 + + [nova-compute-ironic:children] + nova-compute-ironic-1 + nova-compute-ironic-2 + nova-compute-ironic-3 + nova-compute-ironic-4 + +.. note:: + + The number of ``nova-compute-ironic-N`` groups must equal the length of + ``nova_multi_compute_ironic_config``. This variable is an ordered list, + where the first item maps to ``nova-compute-ironic-1``, the second item + to ``nova-compute-ironic-2`` and so forth. + +.. note:: + + A 'cleanup' function is provided which assists in 'failing over' + service instances to other hosts. For example, if ``controller-01`` + was to be taken down for maintenance, replacing it with ``controller-02`` + in the ``nova-compute-ironic-1`` group and re-deploying the ``nova`` + service would result in the service being removed from ``controller-01`` + and re-deployed on ``controller-02``. The cleanup function cannot + currently handle downsizing the number of service instances. In this case + the redundant service instances must be cleaned up manually. For obvious + reasons the cleanup function cannot remove a service from a failed node, + and in such a case, you must be careful not to allow a second identical + service instance to start when the failed node is recovered. + +The ``nova-compute-ironic`` service instances may be configured +individually via the existing override mechanism. For example, the +creation of ``nova/nova-compute-ironic-1.conf`` will allow variables +for that specific service to be overridden. + OpenStack policy customisation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -216,7 +323,7 @@ adding: .. code-block:: yaml - enable_haproxy: "no" + enable_haproxy: false Note this method is not recommended and generally not tested by the Kolla community, but included since sometimes a free IP is not available @@ -233,7 +340,7 @@ first disable the deployment of the central logging. .. code-block:: yaml - enable_central_logging: "no" + enable_central_logging: false Now you can use the parameter ``elasticsearch_address`` to configure the address of the external Elasticsearch environment. diff --git a/doc/source/admin/mariadb-backup-and-restore.rst b/doc/source/admin/mariadb-backup-and-restore.rst index 596b7f952..f6e77fe4b 100644 --- a/doc/source/admin/mariadb-backup-and-restore.rst +++ b/doc/source/admin/mariadb-backup-and-restore.rst @@ -27,7 +27,7 @@ Firstly, enable backups via ``globals.yml``: .. code-block:: console - enable_mariabackup: "yes" + enable_mariabackup: true Then, kick off a reconfiguration of MariaDB: diff --git a/doc/source/admin/tls.rst b/doc/source/admin/tls.rst index 3183c45e8..a78f4c599 100644 --- a/doc/source/admin/tls.rst +++ b/doc/source/admin/tls.rst @@ -48,10 +48,10 @@ APIs, configure the following in ``globals.yml``: .. code-block:: yaml - kolla_enable_tls_internal: "yes" - kolla_enable_tls_external: "yes" - kolla_enable_tls_backend: "yes" - kolla_copy_ca_into_containers: "yes" + kolla_enable_tls_internal: true + kolla_enable_tls_external: true + kolla_enable_tls_backend: true + kolla_copy_ca_into_containers: true If deploying on Debian or Ubuntu: @@ -100,13 +100,13 @@ encryption: .. code-block:: yaml - kolla_enable_tls_external: "yes" + kolla_enable_tls_external: true To enable internal TLS encryption: .. code-block:: yaml - kolla_enable_tls_internal: "yes" + kolla_enable_tls_internal: true Two certificate files are required to use TLS securely with authentication, which will be provided by your Certificate Authority: @@ -218,8 +218,18 @@ Enabling TLS on the backend services secures communication between the HAProxy listing on the internal/external VIP and the OpenStack services. It also enables secure end-to-end communication between OpenStack services that support TLS termination. The OpenStack services that support -backend TLS termination in Victoria are: Nova, Ironic, Neutron, Keystone, -Glance, Heat, Placement, Horizon, Barbican, and Cinder. +backend TLS termination are: + +* Barbican +* Cinder +* Glance +* Heat +* Horizon +* Ironic +* Keystone +* Neutron +* Nova +* Placement The configuration variables that control back-end TLS for service endpoints are: @@ -235,11 +245,11 @@ communication: .. code-block:: yaml - kolla_enable_tls_backend: "yes" + kolla_enable_tls_backend: true It is also possible to enable back-end TLS on a per-service basis. For example, to enable back-end TLS for Keystone, set ``keystone_enable_tls_backend`` to -``yes``. +``true``. The default values for ``haproxy_backend_cacert`` and ``haproxy_backend_cacert_dir`` should suffice if the certificate is in the @@ -284,7 +294,7 @@ disable verification of the backend certificate: .. code-block:: yaml - kolla_verify_tls_backend: "no" + kolla_verify_tls_backend: false Generating TLS certificates with Let's Encrypt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -297,7 +307,7 @@ must be configured in ``globals.yml``: .. code-block:: yaml - enable_letsencrypt: "yes" + enable_letsencrypt: true letsencrypt_email: "<The email used for registration and recovery contact>" The Let's Encrypt container will attempt to renew your certificates every 12 diff --git a/doc/source/reference/bare-metal/ironic-guide.rst b/doc/source/reference/bare-metal/ironic-guide.rst index 962ece762..75c3865f2 100644 --- a/doc/source/reference/bare-metal/ironic-guide.rst +++ b/doc/source/reference/bare-metal/ironic-guide.rst @@ -16,7 +16,7 @@ Enable Ironic in ``/etc/kolla/globals.yml``: .. code-block:: yaml - enable_ironic: "yes" + enable_ironic: true In the same file, define a network interface as the default NIC for dnsmasq and define a network to be used for the Ironic cleaning network: @@ -125,7 +125,7 @@ PXE filter service: .. code-block:: yaml - enable_ironic_pxe_filter: "yes" + enable_ironic_pxe_filter: true The PXE filter container runs alongside ``ironic-dnsmasq`` and cleans up stale DHCP entries. It is especially useful when auto discovery is enabled and when @@ -189,20 +189,20 @@ keystone could be installed in one region (let's say region 1) and ironic - in another region (let's say region 2). In this case we don't install keystone together with ironic in region 2, but have to configure ironic to connect to existing keystone in region 1. To deploy ironic in this way we have to set -variable ``enable_keystone`` to ``"no"``. +variable ``enable_keystone`` to ``false``. .. code-block:: yaml - enable_keystone: "no" + enable_keystone: false It will prevent keystone from being installed in region 2. To add keystone-related sections in ironic.conf, it is also needed to set -variable ``ironic_enable_keystone_integration`` to ``"yes"`` +variable ``ironic_enable_keystone_integration`` to ``true`` .. code-block:: yaml - ironic_enable_keystone_integration: "yes" + ironic_enable_keystone_integration: true Avoiding problems with high availability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/reference/compute/nova-cells-guide.rst b/doc/source/reference/compute/nova-cells-guide.rst index a808bc083..616ba0a5f 100644 --- a/doc/source/reference/compute/nova-cells-guide.rst +++ b/doc/source/reference/compute/nova-cells-guide.rst @@ -170,7 +170,7 @@ Support for deployment of multiple cells is disabled by default - nova is deployed in single conductor mode. Deployment of multiple cells may be enabled by setting ``enable_cells`` to -``yes`` in ``globals.yml``. This deploys nova in superconductor mode, with +``true`` in ``globals.yml``. This deploys nova in superconductor mode, with separate conductors for each cell. Naming cells diff --git a/doc/source/reference/compute/nova-fake-driver.rst b/doc/source/reference/compute/nova-fake-driver.rst index df003f8f4..bef4d1781 100644 --- a/doc/source/reference/compute/nova-fake-driver.rst +++ b/doc/source/reference/compute/nova-fake-driver.rst @@ -29,7 +29,7 @@ the command line options. .. code-block:: yaml - enable_nova_fake: "yes" + enable_nova_fake: true num_nova_fake_per_node: 5 Each Compute node will run 5 ``nova-compute`` containers and 5 diff --git a/doc/source/reference/compute/nova-guide.rst b/doc/source/reference/compute/nova-guide.rst index 8e083f241..1069030bb 100644 --- a/doc/source/reference/compute/nova-guide.rst +++ b/doc/source/reference/compute/nova-guide.rst @@ -7,7 +7,7 @@ this is via Virtual Machines (VMs), but may also be via bare metal servers if Nova is coupled with Ironic. Nova is enabled by default, but may be disabled by setting ``enable_nova`` to -``no`` in ``globals.yml``. +``false`` in ``globals.yml``. Virtualisation Drivers ====================== @@ -43,7 +43,22 @@ Consoles The console driver may be selected via ``nova_console`` in ``globals.yml``. Valid options are ``none``, ``novnc`` and ``spice``. Additionally, serial console support can be enabled by setting -``enable_nova_serialconsole_proxy`` to ``yes``. +``enable_nova_serialconsole_proxy`` to ``true``. + +``spice`` consoles have additional configuration options used by Kolla Ansible: + +* nova_spice_html5: configures whether the HTML5 transcoding proxy used by + Horizon is enabled, and defaults to ``true``. +* nova_spice_image_compression: which compression algorithm to use for images + when using the SPICE console type. Defaults to ``auto_glz``. +* nova_spice_jpeg_compression: whether or not to use JPEG compression with + SPICE consoles. Defaults to ``auto``. +* nova_spice_zlib_compression: whether or not to use zlib compression with + SPICE consoles. Defaults to ``auto``. +* nova_spice_playback_compression: whether or not to use compression for video + playback. Defaults to ``true``. +* nova_spice_streaming_mode: what streaming mode to use with SPICE consoles. + Defaults to ``filter``. Cells ===== diff --git a/doc/source/reference/compute/zun-guide.rst b/doc/source/reference/compute/zun-guide.rst index 9959dede1..8df209a73 100644 --- a/doc/source/reference/compute/zun-guide.rst +++ b/doc/source/reference/compute/zun-guide.rst @@ -17,11 +17,11 @@ following variables: .. code-block:: yaml - enable_zun: "yes" - enable_kuryr: "yes" - enable_etcd: "yes" - docker_configure_for_zun: "yes" - containerd_configure_for_zun: "yes" + enable_zun: true + enable_kuryr: true + enable_etcd: true + docker_configure_for_zun: true + containerd_configure_for_zun: true Docker reconfiguration requires rebootstrapping before deploy. Make sure you understand the consequences of restarting Docker. diff --git a/doc/source/reference/containers/kuryr-guide.rst b/doc/source/reference/containers/kuryr-guide.rst index f748d16c5..f85451d57 100644 --- a/doc/source/reference/containers/kuryr-guide.rst +++ b/doc/source/reference/containers/kuryr-guide.rst @@ -33,8 +33,8 @@ following variables .. code-block:: yaml - enable_etcd: "yes" - enable_kuryr: "yes" + enable_etcd: true + enable_kuryr: true Deploy the OpenStack cloud and kuryr network plugin diff --git a/doc/source/reference/databases/external-mariadb-guide.rst b/doc/source/reference/databases/external-mariadb-guide.rst index 90b5f7908..55cba4c2b 100644 --- a/doc/source/reference/databases/external-mariadb-guide.rst +++ b/doc/source/reference/databases/external-mariadb-guide.rst @@ -31,7 +31,7 @@ by ensuring the following line exists within ``/etc/kolla/globals.yml`` : .. code-block:: yaml - enable_mariadb: "no" + enable_mariadb: false There are two ways in which you can use external MariaDB: * Using an already load-balanced MariaDB address @@ -60,7 +60,7 @@ need to do the following: .. note:: - If ``enable_external_mariadb_load_balancer`` is set to ``no`` + If ``enable_external_mariadb_load_balancer`` is set to ``false`` (default), the external DB load balancer should be accessible from all nodes during your deployment. @@ -87,7 +87,7 @@ according to the following configuration: .. code-block:: yaml - enable_external_mariadb_load_balancer: yes + enable_external_mariadb_load_balancer: true Using External MariaDB with a privileged user ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/reference/databases/mariadb-guide.rst b/doc/source/reference/databases/mariadb-guide.rst index c4a40740e..b09ab11b6 100644 --- a/doc/source/reference/databases/mariadb-guide.rst +++ b/doc/source/reference/databases/mariadb-guide.rst @@ -69,3 +69,108 @@ Backup and restore is working only for default shard as kolla currently using HAProxy solution for MariaDB loadbalancer which is simple TCP and has configured only default shard hosts as backends, therefore backup script will reach only default shard on ``kolla_internal_vip_address``. + +.. _mariadb-notifications: + +Cluster Event Notifications +--------------------------- + +Kolla Ansible supports native MariaDB Galera cluster notifications. This allows +operators to execute custom logic whenever a node status or cluster membership +changes. + +To enable this feature, you must provide a custom script named +``wsrep-notify.sh`` in the following directory on the control host: +``/etc/kolla/config/mariadb/wsrep-notify.sh``. + +Kolla Ansible will automatically detect the presence of this file, copy it to +the MariaDB nodes, and configure the ``wsrep_notify_cmd`` directive in the +MariaDB configuration. + +Example 1: Integration with Prometheus Alertmanager +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can use this feature to send alerts directly to Prometheus Alertmanager. +Save the following content as ``/etc/kolla/config/mariadb/wsrep-notify.sh``: + +.. code-block:: bash + + #!/bin/bash + + # List of Alertmanager instances (direct IP addresses) + # Using kolla_address to bypass VIP for higher reliability + ALERTMANAGERS=( + {% for host in groups['prometheus-alertmanager'] %} + "{{ internal_protocol }}://{{ 'api' | kolla_address(host) | + put_address_in_context('url') }}:{{ hostvars[host] + ['prometheus_alertmanager_port'] }}/api/v2/alerts" + {% endfor %} + ) + + # Authentication credentials from Kolla configuration + AUTH="{{ prometheus_alertmanager_user }}:{{ + prometheus_alertmanager_password }}" + HOSTNAME=$(hostname) + + # Prepare the JSON payload for the Alertmanager API + PAYLOAD=$(cat <<EOF + [ + { + "labels": { + "alertname": "GaleraEvent", + "severity": "warning", + "instance": "$HOSTNAME" + }, + "annotations": { + "description": "Galera cluster event detected: $*", + "summary": "Galera Status Change on $HOSTNAME" + } + } + ] + EOF + ) + + # Iterate through instances until the first successful POST + for URL in "${ALERTMANAGERS[@]}"; do + echo "Attempting to send alert to: $URL" + if curl -X POST "$URL" \ + -u "$AUTH" \ + -H "Content-Type: application/json" \ + -d "$PAYLOAD" \ + --fail --silent --show-error; then + echo "Alert sent successfully." + exit 0 + fi + echo "Failed to reach $URL, trying next instance..." + done + + echo "Error: Could not send alert to any Alertmanager instance." + exit 1 + +.. note:: + + When providing this script, ensure it has the correct permissions. Kolla + Ansible will attempt to set execution permissions (``0755``) automatically + during the deployment. + +Example 2: Logging Cluster Changes to a File +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Alternatively, you can log all cluster events to a local file for later audit +or simple monitoring. Save the following content as +``/etc/kolla/config/mariadb/wsrep-notify.sh``: + +.. code-block:: bash + + #!/bin/bash + + LOG_FILE="/var/log/kolla/mariadb/galera_cluster_events.log" + TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S') + + echo "[$TIMESTAMP] Host: $HOSTNAME | Event: $*" >> "$LOG_FILE" + +.. note:: + + When providing this script, ensure it has the correct permissions. Kolla + Ansible will attempt to set execution permissions (``0755``) automatically + during the deployment. diff --git a/doc/source/reference/high-availability/haproxy-guide.rst b/doc/source/reference/high-availability/haproxy-guide.rst index 0d1219789..02e09158b 100644 --- a/doc/source/reference/high-availability/haproxy-guide.rst +++ b/doc/source/reference/high-availability/haproxy-guide.rst @@ -19,8 +19,8 @@ setting the following in ``/etc/kolla/globals.yml``: .. code-block:: yaml - enable_haproxy: "no" - enable_keepalived: "no" + enable_haproxy: false + enable_keepalived: false Single external frontend for services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -91,7 +91,7 @@ disabled by setting the following in ``/etc/kolla/globals.yml``: .. code-block:: yaml - haproxy_enable_http2: "no" + haproxy_enable_http2: false SSL/TLS Settings ---------------- diff --git a/doc/source/reference/logging-and-monitoring/central-logging-guide.rst b/doc/source/reference/logging-and-monitoring/central-logging-guide.rst index f9b96697d..870be297f 100644 --- a/doc/source/reference/logging-and-monitoring/central-logging-guide.rst +++ b/doc/source/reference/logging-and-monitoring/central-logging-guide.rst @@ -16,7 +16,7 @@ the following: .. code-block:: yaml - enable_central_logging: "yes" + enable_central_logging: true OpenSearch ~~~~~~~~~~ diff --git a/doc/source/reference/logging-and-monitoring/grafana-guide.rst b/doc/source/reference/logging-and-monitoring/grafana-guide.rst index 6f89c2016..412ca88e1 100644 --- a/doc/source/reference/logging-and-monitoring/grafana-guide.rst +++ b/doc/source/reference/logging-and-monitoring/grafana-guide.rst @@ -20,13 +20,13 @@ and change the following: .. code-block:: yaml - enable_grafana: "yes" + enable_grafana: true If you would like to set up Prometheus as a data source, additionally set: .. code-block:: yaml - enable_prometheus: "yes" + enable_prometheus: true Please follow :doc:`Prometheus Guide <prometheus-guide>` for more information. diff --git a/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst b/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst index 9951d4472..fd56f65dc 100644 --- a/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst +++ b/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst @@ -22,8 +22,8 @@ Enable ``OSprofiler`` in ``/etc/kolla/globals.yml`` file: .. code-block:: yaml - enable_osprofiler: "yes" - enable_elasticsearch: "yes" + enable_osprofiler: true + enable_elasticsearch: true Verify operation ---------------- diff --git a/doc/source/reference/logging-and-monitoring/prometheus-guide.rst b/doc/source/reference/logging-and-monitoring/prometheus-guide.rst index d1e4109fc..0680099a3 100644 --- a/doc/source/reference/logging-and-monitoring/prometheus-guide.rst +++ b/doc/source/reference/logging-and-monitoring/prometheus-guide.rst @@ -18,13 +18,13 @@ and change the following: .. code-block:: yaml - enable_prometheus: "yes" + enable_prometheus: true Note: This will deploy Prometheus version 2.x. Any potentially existing Prometheus 1.x instances deployed by previous Kolla Ansible releases will conflict with current version and should be manually stopped and/or removed. If you would like to stay with version 1.x, set the ``enable_prometheus`` -variable to ``no``. +variable to ``false``. In order to remove leftover volume containing Prometheus 1.x data, execute: diff --git a/doc/source/reference/message-queues/external-rabbitmq-guide.rst b/doc/source/reference/message-queues/external-rabbitmq-guide.rst index 10277f641..571751657 100644 --- a/doc/source/reference/message-queues/external-rabbitmq-guide.rst +++ b/doc/source/reference/message-queues/external-rabbitmq-guide.rst @@ -23,7 +23,7 @@ by ensuring the following line exists within ``/etc/kolla/globals.yml`` : .. code-block:: yaml - enable_rabbitmq: "no" + enable_rabbitmq: false Overwriting transport_url within ``globals.yml`` diff --git a/doc/source/reference/networking/designate-guide.rst b/doc/source/reference/networking/designate-guide.rst index aa0932b87..a46eb4da3 100644 --- a/doc/source/reference/networking/designate-guide.rst +++ b/doc/source/reference/networking/designate-guide.rst @@ -23,7 +23,7 @@ Enable Designate service in ``/etc/kolla/globals.yml`` .. code-block:: yaml - enable_designate: "yes" + enable_designate: true neutron_dns_domain: "example.org." .. important:: @@ -54,7 +54,7 @@ Configure Designate options in ``/etc/kolla/globals.yml`` enable a supported coordination backend, currently only ``valkey`` is supported. The backend choice can be overridden via the ``designate_coordination_backend`` variable. It defaults to ``valkey`` - when ``valkey`` is enabled (``enable_valkey`` is set to ``yes``). + when ``valkey`` is enabled (``enable_valkey`` is set to ``true``). The following additional variables are required depending on which backend you intend to use: @@ -108,7 +108,7 @@ to trigger record creation & deletion. .. note:: Service ``designate-sink`` in kolla deployments is disabled by default - and can be enabled by ``designate_enable_notifications_sink: yes``. + and can be enabled by ``designate_enable_notifications_sink: true``. Create default Designate Zone for Neutron: diff --git a/doc/source/reference/networking/dpdk.rst b/doc/source/reference/networking/dpdk.rst index 478596a66..96f9e52e5 100644 --- a/doc/source/reference/networking/dpdk.rst +++ b/doc/source/reference/networking/dpdk.rst @@ -71,8 +71,8 @@ To enable ovs-dpdk, add the following configuration to .. code-block:: yaml ovs_datapath: "netdev" - enable_ovs_dpdk: yes - enable_openvswitch: yes + enable_ovs_dpdk: true + enable_openvswitch: true tunnel_interface: "dpdk_bridge" neutron_bridge_name: "dpdk_bridge" diff --git a/doc/source/reference/networking/neutron-extensions.rst b/doc/source/reference/networking/neutron-extensions.rst index 2e8be4b13..2dbdb441e 100644 --- a/doc/source/reference/networking/neutron-extensions.rst +++ b/doc/source/reference/networking/neutron-extensions.rst @@ -14,7 +14,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows: .. code-block:: yaml - enable_neutron_sfc: "yes" + enable_neutron_sfc: true Verification ------------ @@ -37,7 +37,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows: .. code-block:: yaml - enable_neutron_fwaas: "yes" + enable_neutron_fwaas: true For more information on FWaaS in Neutron refer to the :neutron-doc:`Neutron FWaaS docs <admin/fwaas.html>`. @@ -45,6 +45,13 @@ For more information on FWaaS in Neutron refer to the Neutron VPNaaS (VPN-as-a-Service) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. warning:: + + OVN VPNaaS is currently not supported on RHEL 10 based distributions + (e.g., Rocky Linux 10, CentOS Stream 10) due to an upstream bug in + Neutron. See `LP#2146308 <https://bugs.launchpad.net/neutron/+bug/2146308>`_ + for details. + Preparation and deployment -------------------------- @@ -52,7 +59,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows: .. code-block:: yaml - enable_neutron_vpnaas: "yes" + enable_neutron_vpnaas: true Verification ------------ @@ -60,15 +67,20 @@ Verification VPNaaS is a complex subject, hence this document provides directions for a simple smoke test to verify the service is up and running. -On the network node(s), the ``neutron_vpnaas_agent`` should be up (image naming -and versioning may differ depending on deploy configuration): +In ml2/ovn setups a special neutron_ovn_vpn_agent is running on neutron +node(s). +Version may differ depending on deploy configuration: .. code-block:: console - # docker ps --filter name=neutron_vpnaas_agent + # docker ps --filter name=neutron_ovn_vpn_agent + + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + 7f6efad28d30 kolla/neutron-ovn-vpn-agent:18.1.0 "dumb-init --single-…" 7 days ago Up 7 days (healthy) neutron_ovn_vpn_agent + +On ml2/ovs deployments there is no special agent. +The vpnaas code is running inside the neutron_l3_agent container. - CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES - 97d25657d55e operator:5000/kolla/centos-source-neutron-vpnaas-agent:4.0.0 "kolla_start" 44 minutes ago Up 44 minutes neutron_vpnaas_agent .. warning:: @@ -92,21 +104,20 @@ Verify both VPN services are active: .. code-block:: console - # neutron vpn-service-list + # openstack vpn service list - +--------------------------------------+----------+--------------------------------------+--------+ - | id | name | router_id | status | - +--------------------------------------+----------+--------------------------------------+--------+ - | ad941ec4-5f3d-4a30-aae2-1ab3f4347eb1 | vpn_west | 051f7ce3-4301-43cc-bfbd-7ffd59af539e | ACTIVE | - | edce15db-696f-46d8-9bad-03d087f1f682 | vpn_east | 058842e0-1d01-4230-af8d-0ba6d0da8b1f | ACTIVE | - +--------------------------------------+----------+--------------------------------------+--------+ + +--------------------------------------+----------+--------------------------------------+--------+--------+-------+--------+ + | ID | Name | Router | Subnet | Flavor | State | Status | + +--------------------------------------+----------+--------------------------------------+--------+--------+-------+--------+ + | 03f85023-28d9-4f35-a10e-2c8dd3c11b65 | vpn_west | e3603217-fd22-404c-b27e-9285c2a79a17 | None | None | True | ACTIVE | + | 1abdc71a-2eb7-4b2a-8871-eb9d91f39957 | vpn_east | 3485bdd2-4c42-449e-ae9f-d071a8cb9e5c | None | None | True | ACTIVE | + +--------------------------------------+----------+--------------------------------------+--------+--------+-------+--------+ Two VMs can now be booted, one on vpn_east, the other on vpn_west, and encrypted ping packets observed being sent from one to the other. -For more information on this and VPNaaS in Neutron refer to the -:neutron-vpnaas-doc:`Neutron VPNaaS Testing <contributor/index.html#testing>` -and the `OpenStack wiki <https://wiki.openstack.org/wiki/Neutron/VPNaaS>`_. +For more information on VPNaaS in Neutron refer to the +`OpenStack docs <https://docs.openstack.org/neutron-vpnaas>`_. Trunking ~~~~~~~~ @@ -119,7 +130,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows: .. code-block:: yaml - enable_neutron_trunk: "yes" + enable_neutron_trunk: true Neutron Logging Framework ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -131,7 +142,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows: .. code-block:: yaml - enable_neutron_packet_logging: "yes" + enable_neutron_packet_logging: true For OVS deployment, you need to override the firewall driver in `openvswitch_agent.ini` to: diff --git a/doc/source/reference/networking/neutron.rst b/doc/source/reference/networking/neutron.rst index 3fec073a5..b4f7a884f 100644 --- a/doc/source/reference/networking/neutron.rst +++ b/doc/source/reference/networking/neutron.rst @@ -109,7 +109,7 @@ To use provider networks in instances you also need to set the following in .. code-block:: yaml - enable_neutron_provider_networks: yes + enable_neutron_provider_networks: true For provider networks, compute hosts must have an external bridge created and configured by Ansible (this is also necessary when @@ -188,7 +188,7 @@ L3 and DHCP agents can be created in a high availability (HA) state with: .. code-block:: yaml - enable_neutron_agent_ha: "yes" + enable_neutron_agent_ha: true This allows networking to fail over across controllers if the active agent is stopped. If this option is enabled, it can be advantageous to also set: @@ -275,7 +275,7 @@ In order to deploy Neutron OVN Agent you need to set the following: .. path /etc/kolla/globals.yml .. code-block:: yaml - neutron_enable_ovn_agent: "yes" + neutron_enable_ovn_agent: true Currently the agent is only needed for QoS for hardware offloaded ports. @@ -306,7 +306,7 @@ set the following (assuming neutron SR-IOV agent is also enabled using .. path /etc/kolla/globals.yml .. code-block:: yaml - enable_neutron_mlnx: "yes" + enable_neutron_mlnx: true Additionally, you will also need to provide physnet:interface mappings via ``neutron_mlnx_physnet_mappings`` which is presented to diff --git a/doc/source/reference/networking/octavia.rst b/doc/source/reference/networking/octavia.rst index 7a29d67fa..33a64bd6c 100644 --- a/doc/source/reference/networking/octavia.rst +++ b/doc/source/reference/networking/octavia.rst @@ -14,7 +14,7 @@ Enable the octavia service in ``globals.yml``: .. code-block:: yaml - enable_octavia: "yes" + enable_octavia: true Amphora provider ================ @@ -96,7 +96,7 @@ networks: .. code-block:: yaml - enable_neutron_provider_networks: yes + enable_neutron_provider_networks: true Configure the name of the network interface on the controllers used to access the Octavia management network. If using a VLAN provider network, ensure that @@ -219,7 +219,7 @@ For example: allocation_pool_start: "10.1.2.100" allocation_pool_end: "10.1.2.200" gateway_ip: "10.1.2.1" - enable_dhcp: yes + enable_dhcp: true Deploy Octavia with Kolla Ansible: @@ -252,16 +252,6 @@ as follows: Ensure that you have executed ``kolla-ansible post-deploy`` and set ``enable_octavia`` to yes in ``global.yml`` -.. note:: - - In Train and earlier releases, resources should be registered in the - ``admin`` project. This is configured via ``octavia_service_auth_project``, - and may be set to ``service`` to avoid a breaking change when upgrading to - Ussuri. Changing the project on an existing system requires at a minimum - registering a new security group in the new project. Ideally the flavor and - network should be recreated in the new project, although this will impact - existing Amphorae. - Amphora flavor ~~~~~~~~~~~~~~ diff --git a/doc/source/reference/networking/sriov.rst b/doc/source/reference/networking/sriov.rst index 73afa7b0f..94417bfa0 100644 --- a/doc/source/reference/networking/sriov.rst +++ b/doc/source/reference/networking/sriov.rst @@ -21,7 +21,7 @@ shows which automatically appends ``sriovnicswitch`` to the .. path /etc/kolla/globals.yml .. code-block:: yaml - enable_neutron_sriov: "yes" + enable_neutron_sriov: true It is also a requirement to define physnet:interface mappings for all SRIOV devices as shown in the following example where ``sriovtenant1`` is the diff --git a/doc/source/reference/orchestration-and-nfv/tacker-guide.rst b/doc/source/reference/orchestration-and-nfv/tacker-guide.rst index 4c99e72e1..95e82031e 100644 --- a/doc/source/reference/orchestration-and-nfv/tacker-guide.rst +++ b/doc/source/reference/orchestration-and-nfv/tacker-guide.rst @@ -40,8 +40,8 @@ In order to enable them, you need to edit the file .. code-block:: yaml - enable_tacker: "yes" - enable_barbican: "yes" + enable_tacker: true + enable_barbican: true .. warning:: diff --git a/doc/source/reference/shared-services/glance-guide.rst b/doc/source/reference/shared-services/glance-guide.rst index 082bd40c6..d8e73e44d 100644 --- a/doc/source/reference/shared-services/glance-guide.rst +++ b/doc/source/reference/shared-services/glance-guide.rst @@ -99,7 +99,7 @@ need to be enabled. .. code-block:: yaml - glance_enable_rolling_upgrade: "yes" + glance_enable_rolling_upgrade: true .. warning:: @@ -118,7 +118,7 @@ It is the default mode, ensure rolling upgrade method is not enabled. .. code-block:: yaml - glance_enable_rolling_upgrade: "no" + glance_enable_rolling_upgrade: false Other configuration @@ -131,7 +131,7 @@ Glance cache is disabled by default, it can be enabled by: .. code-block:: yaml - enable_glance_image_cache: "yes" + enable_glance_image_cache: true glance_cache_max_size: "10737418240" # 10GB by default .. warning:: @@ -154,7 +154,7 @@ is disabled by default, it can be enabled by: .. code-block:: yaml - glance_enable_property_protection: "yes" + glance_enable_property_protection: true and defining ``property-protections-rules.conf`` under @@ -170,7 +170,7 @@ is disabled by default, it can be enabled by: .. code-block:: yaml - glance_enable_interoperable_image_import: "yes" + glance_enable_interoperable_image_import: true and defining ``glance-image-import.conf`` under ``{{ node_custom_config }}/glance/``. diff --git a/doc/source/reference/shared-services/keystone-guide.rst b/doc/source/reference/shared-services/keystone-guide.rst index b92230dcb..173766022 100644 --- a/doc/source/reference/shared-services/keystone-guide.rst +++ b/doc/source/reference/shared-services/keystone-guide.rst @@ -96,13 +96,13 @@ used by OpenStack command line client. Example config shown below: keystone_federation_oidc_jwks_uri: "https://<AUTH PROVIDER>/<ID>/discovery/v2.0/keys" -Some identity providers need additional mod_auth_openidc config. -Example for Keycloak shown below: +Some identity providers need additional ``mod_auth_openidc`` config, which can +be passed with the ``keystone_federation_oidc_additional_options`` variable: .. code-block:: yaml keystone_federation_oidc_additional_options: - OIDCTokenBindingPolicy: disabled + OIDCOutgoingProxy: "http://proxy.example.com" When using OIDC, operators can also use the following variable to customize the delay to retry authenticating in the IdP if the @@ -131,6 +131,11 @@ openstack_domain The OpenStack domain that the Identity Provider belongs. +.. note:: + Kolla-Ansible does not support duplicate openstack_domain names, + where the ID of the domain is different, but the name is the same. + This is an edge case that is hard to take into account. + protocol ******** diff --git a/doc/source/reference/shared-services/skyline-guide.rst b/doc/source/reference/shared-services/skyline-guide.rst index fb735c997..4aea2beb7 100644 --- a/doc/source/reference/shared-services/skyline-guide.rst +++ b/doc/source/reference/shared-services/skyline-guide.rst @@ -12,18 +12,18 @@ Single Sign On (SSO) Skyline supports SSO with an Openid IdP. When you configure an IdP with protocol openid, Kolla will automatically enable SSO and set up the trusted dashboard url for Keystone. If you don't want to use SSO in Skyline, you can -disable it by setting ``skyline_enable_sso`` to "no": +disable it by setting ``skyline_enable_sso`` to ``false``: .. code-block:: yaml - skyline_enable_sso: "no" + skyline_enable_sso: false If you want to enable it without setting up the IdP with Kolla you can simply enable it with: .. code-block:: yaml - skyline_enable_sso: "yes" + skyline_enable_sso: true Customize logos ~~~~~~~~~~~~~~~ diff --git a/doc/source/reference/storage/cinder-guide-lightbits.rst b/doc/source/reference/storage/cinder-guide-lightbits.rst index b09d0e4a1..dc1ea7ec0 100644 --- a/doc/source/reference/storage/cinder-guide-lightbits.rst +++ b/doc/source/reference/storage/cinder-guide-lightbits.rst @@ -13,7 +13,7 @@ configure the ``Lightbits labs`` Cinder driver in .. code-block:: yaml - enable_cinder_backend_lightbits: "yes" + enable_cinder_backend_lightbits: true .. end diff --git a/doc/source/reference/storage/cinder-guide-pure.rst b/doc/source/reference/storage/cinder-guide-pure.rst index 0970d98ea..c26104761 100644 --- a/doc/source/reference/storage/cinder-guide-pure.rst +++ b/doc/source/reference/storage/cinder-guide-pure.rst @@ -12,7 +12,7 @@ configure the ``FlashArray iSCSI`` Cinder driver in ``/etc/kolla/globals.yml``. .. code-block:: yaml - enable_cinder_backend_pure_iscsi: "yes" + enable_cinder_backend_pure_iscsi: true .. end @@ -21,7 +21,7 @@ configure the ``FlashArray FC`` Cinder driver in ``/etc/kolla/globals.yml``. .. code-block:: yaml - enable_cinder_backend_pure_fc: "yes" + enable_cinder_backend_pure_fc: true .. end @@ -31,7 +31,7 @@ configure the ``FlashArray NVMe-RoCE`` Cinder driver in .. code-block:: yaml - enable_cinder_backend_pure_roce: "yes" + enable_cinder_backend_pure_roce: true .. end @@ -45,7 +45,7 @@ configure the ``FlashArray NVMe-TCP`` Cinder driver in .. code-block:: yaml - enable_cinder_backend_pure_nvme_tcp: "yes" + enable_cinder_backend_pure_nvme_tcp: true .. end diff --git a/doc/source/reference/storage/cinder-guide-quobyte.rst b/doc/source/reference/storage/cinder-guide-quobyte.rst index ce38223fa..0423756b8 100644 --- a/doc/source/reference/storage/cinder-guide-quobyte.rst +++ b/doc/source/reference/storage/cinder-guide-quobyte.rst @@ -12,7 +12,7 @@ Cinder driver in ``/etc/kolla/globals.yml``. .. code-block:: yaml - enable_cinder_backend_quobyte: "yes" + enable_cinder_backend_quobyte: true .. end diff --git a/doc/source/reference/storage/cinder-guide.rst b/doc/source/reference/storage/cinder-guide.rst index 9f8a5bf2a..9766c053a 100644 --- a/doc/source/reference/storage/cinder-guide.rst +++ b/doc/source/reference/storage/cinder-guide.rst @@ -65,7 +65,15 @@ Enable the ``lvm`` backend in ``/etc/kolla/globals.yml``: .. code-block:: yaml - enable_cinder_backend_lvm: "yes" + enable_cinder_backend_lvm: true + +Edit the inventory file and add ``storage`` group as a child of +``cinder-volume`` group: + +.. code-block:: ini + + [cinder-volume:children] + storage .. note:: @@ -105,7 +113,7 @@ Finally, enable the ``nfs`` backend in ``/etc/kolla/globals.yml``: .. code-block:: yaml - enable_cinder_backend_nfs: "yes" + enable_cinder_backend_nfs: true Validation ~~~~~~~~~~ @@ -151,9 +159,11 @@ Cinder LVM2 backend with iSCSI As of Newton-1 milestone, Kolla supports LVM2 as cinder backend. It is accomplished by introducing two new containers ``tgtd`` and ``iscsid``. -``tgtd`` container serves as a bridge between cinder-volume process and a -server hosting Logical Volume Groups (LVG). ``iscsid`` container serves as -a bridge between nova-compute process and the server hosting LVG. +``tgtd`` container is the target part of iSCSI setup which needs to run +on the ``storage`` Ansible group for exposing volumes from LVM. +``iscsid`` container is the client part of iSCSI setup which needs to run +together with nova-compute for instance access to storage and on hosts +running ``cinder-volume`` and ``cinder-backup`` for volume operations. In order to use Cinder's LVM backend, a LVG named ``cinder-volumes`` should exist on the server and following parameter must be specified in @@ -161,38 +171,7 @@ exist on the server and following parameter must be specified in .. code-block:: yaml - enable_cinder_backend_lvm: "yes" - -For Ubuntu and LVM2/iSCSI -------------------------- - -``iscsd`` process uses configfs which is normally mounted at -``/sys/kernel/config`` to store discovered targets information, on centos/rhel -type of systems this special file system gets mounted automatically, which is -not the case on debian/ubuntu. Since ``iscsid`` container runs on every nova -compute node, the following steps must be completed on every Ubuntu server -targeted for nova compute role. - -* Add configfs module to ``/etc/modules`` -* Rebuild initramfs using: ``update-initramfs -u`` command -* Stop ``open-iscsi`` system service due to its conflicts - with iscsid container. - - Ubuntu 16.04 (systemd): - ``systemctl stop open-iscsi; systemctl stop iscsid`` - -* Make sure configfs gets mounted during a server boot up process. There are - multiple ways to accomplish it, one example: - - .. code-block:: console - - mount -t configfs /etc/rc.local /sys/kernel/config - - .. note:: - - There is currently an issue with the folder /sys/kernel/config as it is - either empty or does not exist in several operating systems, - see `_bug 1631072 <https://bugs.launchpad.net/kolla/+bug/1631072>`__ for more info + enable_cinder_backend_lvm: true Cinder backend with external iSCSI storage ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -202,9 +181,9 @@ the following parameter must be specified in ``globals.yml``: .. code-block:: yaml - enable_cinder_backend_iscsi: "yes" + enable_cinder_backend_iscsi: true -Also ``enable_cinder_backend_lvm`` should be set to ``no`` in this case. +Also ``enable_cinder_backend_lvm`` should be set to ``false`` in this case. Skip Cinder prechecks for Custom backends ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/reference/storage/external-ceph-guide.rst b/doc/source/reference/storage/external-ceph-guide.rst index f37678eb2..49e64d6c3 100644 --- a/doc/source/reference/storage/external-ceph-guide.rst +++ b/doc/source/reference/storage/external-ceph-guide.rst @@ -412,7 +412,7 @@ for Ceph includes following steps: .. code-block:: yaml - enable_manila_backend_cephfs_native: "yes" + enable_manila_backend_cephfs_native: true * Configure Ceph authentication details in ``/etc/kolla/globals.yml``: diff --git a/doc/source/reference/storage/manila-guide.rst b/doc/source/reference/storage/manila-guide.rst index fa0f2f11f..d0d09dce9 100644 --- a/doc/source/reference/storage/manila-guide.rst +++ b/doc/source/reference/storage/manila-guide.rst @@ -39,14 +39,14 @@ Cinder is required, enable it in ``/etc/kolla/globals.yml``: .. code-block:: console - enable_cinder: "yes" + enable_cinder: true Enable Manila and generic back end in ``/etc/kolla/globals.yml``: .. code-block:: console - enable_manila: "yes" - enable_manila_backend_generic: "yes" + enable_manila: true + enable_manila_backend_generic: true By default Manila uses instance flavor id 100 for its file systems. For Manila to work, either create a new nova flavor with id 100 (use *nova flavor-create*) diff --git a/doc/source/reference/storage/manila-hnas-guide.rst b/doc/source/reference/storage/manila-hnas-guide.rst index 7de399828..107205982 100644 --- a/doc/source/reference/storage/manila-hnas-guide.rst +++ b/doc/source/reference/storage/manila-hnas-guide.rst @@ -77,8 +77,8 @@ Enable Shared File Systems service and HNAS driver in .. code-block:: yaml - enable_manila: "yes" - enable_manila_backend_hnas: "yes" + enable_manila: true + enable_manila_backend_hnas: true Configure the OpenStack networking so it can reach HNAS Management interface and HNAS EVS Data interface. diff --git a/doc/source/reference/storage/manila-pure-guide.rst b/doc/source/reference/storage/manila-pure-guide.rst index 46c1f2fdf..9cb3e756a 100644 --- a/doc/source/reference/storage/manila-pure-guide.rst +++ b/doc/source/reference/storage/manila-pure-guide.rst @@ -61,8 +61,8 @@ Enable Shared File Systems service and FlashBlade driver in .. code-block:: yaml - enable_manila: "yes" - enable_manila_backend_flashblade: "yes" + enable_manila: true + enable_manila_backend_flashblade: true Configure the OpenStack networking so it can reach FlashBlade Management interface and FlashBlade Data interface. diff --git a/doc/source/user/multi-regions.rst b/doc/source/user/multi-regions.rst index dcee26d16..8d4c4043a 100644 --- a/doc/source/user/multi-regions.rst +++ b/doc/source/user/multi-regions.rst @@ -29,8 +29,8 @@ Keystone and Horizon are enabled: .. code-block:: console - enable_keystone: "yes" - enable_horizon: "yes" + enable_keystone: true + enable_horizon: true Then, change the value of ``multiple_regions_names`` to add names of other regions. In this example, we consider two regions. The current one, @@ -71,14 +71,6 @@ the value of ``kolla_internal_fqdn`` in RegionOne: keystone_internal_url: "{{ internal_protocol }}://{{ kolla_internal_fqdn_r1 }}:{{ keystone_public_port }}" - openstack_auth: - auth_url: "{{ keystone_internal_url }}" - username: "{{ keystone_admin_user }}" - password: "{{ keystone_admin_password }}" - user_domain_name: "{{ default_user_domain_name }}" - project_name: "{{ keystone_admin_project }}" - domain_name: "default" - .. note:: If the ``kolla_internal_vip_address`` and/or the @@ -151,7 +143,7 @@ unnecessary in this region and run ``kolla-ansible``: .. code-block:: yaml - enable_keystone: "no" - enable_horizon: "no" + enable_keystone: false + enable_horizon: false The configuration is the same for any other region. diff --git a/doc/source/user/operating-kolla.rst b/doc/source/user/operating-kolla.rst index 8e931997d..44e3ddd88 100644 --- a/doc/source/user/operating-kolla.rst +++ b/doc/source/user/operating-kolla.rst @@ -43,7 +43,7 @@ Upgrade procedure .. note:: - If you have set ``enable_cells`` to ``yes`` then you should read the + If you have set ``enable_cells`` to ``true`` then you should read the upgrade notes in the :ref:`Nova cells guide<nova-cells-upgrade>`. Kolla's strategy for upgrades is to never make a mess and to follow consistent @@ -111,8 +111,7 @@ If performing a skip-level (SLURP) upgrade, update ``ansible`` or pip3 install --upgrade 'ansible-core>=|ANSIBLE_CORE_VERSION_MIN|,<|ANSIBLE_CORE_VERSION_MAX|.99' -If upgrading to a Yoga release or later, install or upgrade Ansible Galaxy -dependencies: +Install or upgrade Ansible Galaxy dependencies: .. code-block:: console @@ -150,7 +149,7 @@ For example: .. code-block:: console cp /etc/kolla/passwords.yml passwords.yml.old - cp kolla-ansible/etc/kolla/passwords.yml passwords.yml.new + cp /path/to/venv/share/kolla-ansible/etc/kolla/passwords.yml passwords.yml.new kolla-genpwd -p passwords.yml.new kolla-mergepwd --old passwords.yml.old --new passwords.yml.new --final /etc/kolla/passwords.yml @@ -316,6 +315,8 @@ Tools ----- Kolla ships with several utilities intended to facilitate ease of operation. +If you installed Kolla Ansible in a virtual environment, these scripts are +located in ``/path/to/venv/share/kolla-ansible/tools/``. ``tools/cleanup-containers`` is used to remove deployed containers from the system. This can be useful when you want to do a new clean deployment. It will diff --git a/doc/source/user/quickstart-development.rst b/doc/source/user/quickstart-development.rst index 6e29a2ad5..f61e972cc 100644 --- a/doc/source/user/quickstart-development.rst +++ b/doc/source/user/quickstart-development.rst @@ -98,7 +98,7 @@ Install Kolla-ansible git clone --branch |KOLLA_BRANCH_NAME| https://opendev.org/openstack/kolla-ansible -#. Install requirements of ``kolla`` and ``kolla-ansible``: +#. Install ``kolla-ansible`` and its dependencies: .. code-block:: console @@ -160,8 +160,7 @@ manually or by running random password generator: .. code-block:: console - cd kolla-ansible/tools - ./generate_passwords.py + kolla-genpwd Kolla globals.yml ----------------- @@ -244,7 +243,7 @@ There are a few options that are required to deploy Kolla Ansible: By default Kolla Ansible provides a bare compute kit, however it does provide support for a vast selection of additional services. To enable them, set - ``enable_*`` to "yes". + ``enable_*`` to ``true``. Kolla now supports many OpenStack services, there is `a list of available services @@ -283,27 +282,28 @@ need to setup basic host-level dependencies, like docker. Kolla Ansible provides a playbook that will install all required services in the correct versions. -The following assumes the use of the ``all-in-one`` inventory. If using a -different inventory, such as ``multinode``, replace the ``-i`` argument -accordingly. +The following assumes the use of the ``all-in-one`` inventory in your +current directory. +If using a different inventory, such as ``multinode``, replace the ``-i`` +argument accordingly. #. Bootstrap servers with kolla deploy dependencies: .. code-block:: console - kolla-ansible bootstrap-servers -i ../all-in-one + kolla-ansible bootstrap-servers -i all-in-one #. Do pre-deployment checks for hosts: .. code-block:: console - kolla-ansible prechecks -i ../all-in-one + kolla-ansible prechecks -i all-in-one #. Finally proceed to actual OpenStack deployment: .. code-block:: console - kolla-ansible deploy -i ../all-in-one + kolla-ansible deploy -i all-in-one When this playbook finishes, OpenStack should be up, running and functional! If error occurs during execution, refer to diff --git a/doc/source/user/quickstart.rst b/doc/source/user/quickstart.rst index f02401fc2..f2978b95a 100644 --- a/doc/source/user/quickstart.rst +++ b/doc/source/user/quickstart.rst @@ -235,11 +235,11 @@ There are a few options that are required to deploy Kolla Ansible: By default Kolla Ansible provides a bare compute kit, however it does provide support for a vast selection of additional services. To enable them, set - ``enable_*`` to "yes". + ``enable_*`` to ``true``. Kolla now supports many OpenStack services, there is `a list of available services - <https://github.com/openstack/kolla-ansible/blob/master/README.rst#openstack-services>`_. + <https://opendev.org/openstack/kolla-ansible/src/branch/|KOLLA_BRANCH_NAME|/README.rst#openstack-services>`_. For more information about service configuration, Please refer to the :kolla-ansible-doc:`Services Reference Guide <reference/index.html>`. diff --git a/doc/source/user/troubleshooting.rst b/doc/source/user/troubleshooting.rst index 76a9ac604..289b89220 100644 --- a/doc/source/user/troubleshooting.rst +++ b/doc/source/user/troubleshooting.rst @@ -48,7 +48,7 @@ Debugging Kolla ~~~~~~~~~~~~~~~ The status of containers after deployment can be determined on the deployment -targets by executing: +targets by executing (use `podman` instead of `docker` if applicable): .. code-block:: console @@ -76,8 +76,10 @@ If the stdout logs are needed, please run: Note that most of the containers don't log to stdout so the above command will provide no information. -To learn more about Docker command line operation please refer to `Docker -documentation <https://docs.docker.com/reference/>`__. +To learn more about container engine command line operation, please refer +to the `Docker +documentation <https://docs.docker.com/reference/>`__ or the `Podman +documentation <https://docs.podman.io/en/stable/Commands.html>`__. The log volume "kolla_logs" is linked to ``/var/log/kolla`` on the host. You can find all kolla logs in there. |