diff options
Diffstat (limited to 'doc')
62 files changed, 1240 insertions, 1247 deletions
diff --git a/doc/requirements.txt b/doc/requirements.txt index da3f3abff..cd53b9f22 100644 --- a/doc/requirements.txt +++ b/doc/requirements.txt @@ -1,12 +1,5 @@ -# The order of packages is significant, because pip processes them in the order -# of appearance. Changing the order has an impact on the overall integration -# process, which may cause wedges in the gate later. -# Order matters to the pip dependency resolver, so sorting this file -# changes how packages are installed. New dependencies should be -# added in alphabetical order, however, some dependencies may need to -# be installed in a specific order. openstackdocstheme>=2.2.1 # Apache-2.0 reno>=3.1.0 # Apache-2.0 sphinx>=2.0.0,!=2.1.0 # BSD sphinxcontrib-svg2pdfconverter>=0.1.0 # BSD -whereto>=0.3.0 # Apache-2.0 +whereto>=0.5.0 # Apache-2.0 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 2f2864cc6..c85a498dc 100644 --- a/doc/source/admin/advanced-configuration.rst +++ b/doc/source/admin/advanced-configuration.rst @@ -8,19 +8,21 @@ Endpoint Network Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When an OpenStack cloud is deployed, the REST API of each service is presented -as a series of endpoints. These endpoints are the admin URL, the internal -URL, and the external URL. +as a series of endpoints. These endpoints are the internal URL, and the +external URL. Kolla offers two options for assigning these endpoints to network addresses: -- Combined - Where all three endpoints share the same IP address -- Separate - Where the external URL is assigned to an IP address that is -different than the IP address shared by the internal and admin URLs + +* Combined - Where both endpoints share the same IP address +* Separate - Where the external URL is assigned to an IP address that is + different than the IP address used by the internal URL The configuration parameters related to these options are: -- kolla_internal_vip_address -- network_interface -- kolla_external_vip_address -- kolla_external_vip_interface + +* kolla_internal_vip_address +* network_interface +* kolla_external_vip_address +* kolla_external_vip_interface For the combined option, set the two variables below, while allowing the other two to accept their default values. In this configuration all REST @@ -50,8 +52,8 @@ a name, like ``www.example.net``, instead of an address like ``10.10.10.254``. If you prefer to use names to address the endpoints in your kolla deployment use the variables: -- kolla_internal_fqdn -- kolla_external_fqdn +* kolla_internal_fqdn +* kolla_external_fqdn .. code-block:: yaml @@ -176,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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -214,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 @@ -231,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. @@ -269,14 +378,6 @@ By default, HAProxy uses ``local1``. syslog_haproxy_facility: "local1" -If Glance TLS backend is enabled (``glance_enable_tls_backend``), the syslog -facility for the ``glance_tls_proxy`` service uses ``local2`` by default. This -can be set via ``syslog_glance_tls_proxy_facility``. - -If Neutron TLS backend is enabled (``neutron_enable_tls_backend``), the syslog -facility for the ``neutron_tls_proxy`` service uses ``local4`` by default. -This can be set via ``syslog_neutron_tls_proxy_facility``. - Mount additional Docker volumes in containers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -314,3 +415,41 @@ To specify additional volumes for a single container, set nova_libvirt_extra_volumes: - "/etc/foo:/etc/foo" + +Migrate container engine +~~~~~~~~~~~~~~~~~~~~~~~~ + +Kolla-Ansible supports two container engines - Docker and Podman. +It is possible to migrate deployed OpenStack between these two engines. +Migration is supported in both directions, meaning it is possible to +migrate from Docker to Podman as well as from Podman to Docker. + +Before starting the migration, you have to change the value of +``kolla_container_engine`` in your ``/etc/kolla/globals.yml`` file to the new +container engine: + +.. code-block:: yaml + + # previous value was docker + kolla_container_engine: podman + +Apart from this change, ``globals.yml`` should stay unchanged. +The same goes for any other config file, such as the inventory file. + +.. warning:: + + Currently, rolling migration is not supported. You have to stop + all virtual machines running in your OpenStack. Otherwise, + migration will become unstable and can fail. + +After editing ``globals.yml`` and stopping virtual machines +migration can be started with the following command: + +.. code-block:: console + + kolla-ansible migrate-container-engine + +.. warning:: + During the migration, all the container volumes will be migrated + under the new container engine. Old container engine system packages will be + removed from the system and all their resources and data will be deleted. diff --git a/doc/source/admin/mariadb-backup-and-restore.rst b/doc/source/admin/mariadb-backup-and-restore.rst index 6ebb73d5b..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: @@ -41,11 +41,11 @@ Backup Procedure To perform a full backup, run the following command: -``kolla-ansible mariadb_backup -i INVENTORY`` +``kolla-ansible mariadb-backup -i INVENTORY`` Or to perform an incremental backup: -``kolla-ansible mariadb_backup -i INVENTORY --incremental`` +``kolla-ansible mariadb-backup -i INVENTORY --incremental`` Kolla doesn't currently manage the scheduling of these backups, so you'll need to configure an appropriate scheduler (i.e cron) to run these commands @@ -83,7 +83,7 @@ following options on the first database node: docker run --rm -it --volumes-from mariadb --name dbrestore \ --volume mariadb_backup:/backup \ - quay.io/openstack.kolla/mariadb-server:|KOLLA_OPENSTACK_RELEASE|-rocky-9 \ + quay.io/openstack.kolla/mariadb-server:|KOLLA_OPENSTACK_RELEASE|-rocky-10 \ /bin/bash (dbrestore) $ cd /backup (dbrestore) $ rm -rf /backup/restore @@ -105,7 +105,7 @@ place, again on the first node: docker run --rm -it --volumes-from mariadb --name dbrestore \ --volume mariadb_backup:/backup \ - quay.io/openstack.kolla/mariadb-server:|KOLLA_OPENSTACK_RELEASE|-rocky-9 \ + quay.io/openstack.kolla/mariadb-server:|KOLLA_OPENSTACK_RELEASE|-rocky-10 \ /bin/bash (dbrestore) $ rm -rf /var/lib/mysql/* (dbrestore) $ rm -rf /var/lib/mysql/\.[^\.]* @@ -127,7 +127,7 @@ pointing to the first node of the cluster: .. code-block:: console - kolla-ansible mariadb_recovery -i multinode -e mariadb_recover_inventory_name=controller1 + kolla-ansible mariadb-recovery -i multinode -e mariadb_recover_inventory_name=controller1 The above procedure is valid also for a disaster recovery scenario. In such case, first copy MariaDB backup file from the external source into @@ -148,7 +148,7 @@ incremental backup, docker run --rm -it --volumes-from mariadb --name dbrestore \ --volume mariadb_backup:/backup --tmpfs /backup/restore \ - quay.io/openstack.kolla/mariadb-server:|KOLLA_OPENSTACK_RELEASE|-rocky-9 \ + quay.io/openstack.kolla/mariadb-server:|KOLLA_OPENSTACK_RELEASE|-rocky-10 \ /bin/bash (dbrestore) $ cd /backup (dbrestore) $ rm -rf /backup/restore diff --git a/doc/source/admin/password-rotation.rst b/doc/source/admin/password-rotation.rst index a56678391..40f4ac9a6 100644 --- a/doc/source/admin/password-rotation.rst +++ b/doc/source/admin/password-rotation.rst @@ -51,7 +51,7 @@ applied this way. * ``osprofiler_secret`` * ``prometheus_alertmanager_password`` * ``qdrouterd_password`` -* ``redis_master_password`` +* ``valkey_master_password`` It is possible to change more secrets however some require manual steps. The manual steps vary depending on the secret. They are listed below in the order @@ -135,7 +135,7 @@ manually. .. code:: bash - mysql --batch -uroot -p + mariadb --batch -uroot -p #. Check the current state of the ``root`` user: diff --git a/doc/source/admin/production-architecture-guide.rst b/doc/source/admin/production-architecture-guide.rst index d1da7eaad..ced3571fa 100644 --- a/doc/source/admin/production-architecture-guide.rst +++ b/doc/source/admin/production-architecture-guide.rst @@ -14,6 +14,8 @@ Node types and services running on them A basic Kolla inventory consists of several types of nodes, known in Ansible as ``groups``. +* Deployment - Host from which you're running kolla-ansible CLI + * Control - Cloud controller nodes which host control services like APIs and databases. This group should have odd number of nodes for quorum. @@ -29,6 +31,14 @@ A basic Kolla inventory consists of several types of nodes, known in Ansible as * Monitoring - Monitor nodes which host monitoring services. +.. warning:: + + All hosts should be hardened and access to them should be limited, + because Ansible can leak administrative passwords and other secrets to + system log. The same leaked passwords can be observed in OpenSearch if + you're pushing your system logs there. + + Network configuration ~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/admin/tls.rst b/doc/source/admin/tls.rst index df93e59ed..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: @@ -80,10 +80,10 @@ TLS Configuration for internal/external VIP The configuration variables that control TLS for the internal and/or external VIP are: -- ``kolla_enable_tls_external`` -- ``kolla_enable_tls_internal`` -- ``kolla_internal_fqdn_cert`` -- ``kolla_external_fqdn_cert`` +* ``kolla_enable_tls_external`` +* ``kolla_enable_tls_internal`` +* ``kolla_internal_fqdn_cert`` +* ``kolla_external_fqdn_cert`` .. note:: @@ -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,28 +218,38 @@ 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: -- ``kolla_enable_tls_backend`` -- ``kolla_tls_backend_cert`` -- ``kolla_tls_backend_key`` -- ``haproxy_backend_cacert`` -- ``haproxy_backend_cacert_dir`` +* ``kolla_enable_tls_backend`` +* ``kolla_tls_backend_cert`` +* ``kolla_tls_backend_key`` +* ``haproxy_backend_cacert`` +* ``haproxy_backend_cacert_dir`` The default state for back-end TLS is disabled. To enable TLS for the back-end 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 @@ -316,19 +326,26 @@ to the HAProxy containers using SSH. with HAProxy. You can configure separate ACME servers for internal and external -certificate requests. - -.. code-block:: yaml - - letsencrypt_external_cert_server: "<ACME server URL for external cert>" - letsencrypt_internal_cert_server: "<ACME server URL for internal cert>" - -.. note:: - - The ``letsencrypt_external_cert_server`` has a default value of - ``https://acme-v02.api.letsencrypt.org/directory``. Ensure that - ``letsencrypt_internal_cert_server`` is reachable from the controller - if you configure it for internal certificate requests. +certificate requests by setting server URL on +``letsencrypt_internal_cert_server`` and +``letsencrypt_external_cert_server`` respectively. +The default is external certificate ACME server set to +``https://acme-v02.api.letsencrypt.org/directory``. + +.. list-table:: Let's Encrypt management + :widths: 28 72 + :header-rows: 1 + + * - Desired outcome + - Settings + * - External only (default) + - Enable Let's Encrypt; no further changes. + * - External + internal + - Set ``letsencrypt_internal_cert_server`` and ensure it is reachable + from the controller. + * - Internal only + - Set ``letsencrypt_external_cert_server: ""`` and set + ``letsencrypt_internal_cert_server``. .. _admin-tls-generating-a-private-ca: diff --git a/doc/source/conf.py b/doc/source/conf.py index add1790c4..af435eeb3 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -142,10 +142,10 @@ else: TESTED_RUNTIMES_GOVERNANCE_URL =\ 'https://governance.openstack.org/tc/reference/runtimes/{}.html'.format(KOLLA_OPENSTACK_RELEASE) -ANSIBLE_CORE_VERSION_MIN = '2.17' -ANSIBLE_CORE_VERSION_MAX = '2.18' -ANSIBLE_VERSION_MIN = '10' -ANSIBLE_VERSION_MAX = '11' +ANSIBLE_CORE_VERSION_MIN = '2.19' +ANSIBLE_CORE_VERSION_MAX = '2.20' +ANSIBLE_VERSION_MIN = '12' +ANSIBLE_VERSION_MAX = '13' GLOBAL_VARIABLE_MAP = { '|ANSIBLE_CORE_VERSION_MIN|': ANSIBLE_CORE_VERSION_MIN, diff --git a/doc/source/contributor/adding-a-new-service.rst b/doc/source/contributor/adding-a-new-service.rst index 6f6a64a0e..967ca139b 100644 --- a/doc/source/contributor/adding-a-new-service.rst +++ b/doc/source/contributor/adding-a-new-service.rst @@ -42,10 +42,10 @@ which Kolla uses throughout and which should be followed. * Log rotation - For OpenStack services there should be a ``cron-logrotate-PROJECT.conf.j2`` - template file in ``ansible/roles/common/templates`` with the following + template file in ``ansible/roles/cron/templates`` with the following content: - .. path ansible/roles/common/templates/cron-logrotate-PROJECT.conf.j2 + .. path ansible/roles/cron/templates/cron-logrotate-PROJECT.conf.j2 .. code-block:: console "/var/log/kolla/PROJECT/*.log" @@ -53,14 +53,14 @@ which Kolla uses throughout and which should be followed. } - For OpenStack services there should be an entry in the ``services`` list - in the ``cron.json.j2`` template file in ``ansible/roles/common/templates``. + in the ``cron.json.j2`` template file in ``ansible/roles/cron/templates``. * Log delivery - For OpenStack services the service should add a new ``rewriterule`` in the ``match`` element in the ``01-rewrite.conf.j2`` template file in - ``ansible/roles/common/templates/conf/filter`` to deliver log messages to - Elasticsearch. + ``ansible/roles/fluentd/templates/conf/filter`` to deliver log messages to + Opensearch. * Documentation @@ -76,16 +76,16 @@ which Kolla uses throughout and which should be followed. Other than the above, most service roles abide by the following pattern: -- ``Register``: Involves registering the service with Keystone, creating +* ``Register``: Involves registering the service with Keystone, creating endpoints, roles, users, etc. -- ``Config``: Distributes the config files to the nodes to be pulled into +* ``Config``: Distributes the config files to the nodes to be pulled into the container on startup. -- ``Bootstrap``: Creating the database (but not tables), database user for +* ``Bootstrap``: Creating the database (but not tables), database user for the service, permissions, etc. -- ``Bootstrap Service``: Starts a one shot container on the host to create +* ``Bootstrap Service``: Starts a one shot container on the host to create the database tables, and other initial run time config. Ansible handlers are used to create or restart containers when necessary. diff --git a/doc/source/contributor/ci-matrix.csv b/doc/source/contributor/ci-matrix.csv new file mode 100644 index 000000000..c9ba67f00 --- /dev/null +++ b/doc/source/contributor/ci-matrix.csv @@ -0,0 +1,23 @@ +Scenario;Disabled;Voting;Tempest;Core;Upgrade;SLURP;Multinode;TLS;Ceph;Cinder;Octavia;Valkey;Notes
+AIO core;–;✅;✅;✅;✅;✅;–;✅;–;–;–;–;"Core OpenStack (Keystone/Glance/Neutron/Nova/Heat) with Horizon; RabbitMQ/MariaDB/Memcached; Fluentd."
+Bifrost;–;–;–;–;–;–;–;–;–;–;–;–;Bifrost baremetal provisioning standalone.
+Cells;–;✅;✅;–;✅;–;✅;–;–;–;–;–;"Nova Cells v2 + ProxySQL; Horizon/Heat on; dashboard sanity."
+Cephadm;–;✅;✅;✅;✅;✅;✅;✅;✅;–;✅;✅;"External Ceph (cinder/glance/nova) + RGW; RabbitMQ tuned."
+Container engine migration;❌;–;✅;✅;–;–;✅;✅;–;–;–;–;"Container engine migration playbook; Tempest smoke; currently disabled (failing)."
+Federation;–;–;✅;–;✅;–;✅;✅;–;–;–;–;Keystone federation behind httpd.
+HAProxy FQDN;–;–;✅;–;–;–;✅;✅;–;–;–;–;HAProxy VIP/FQDN handling.
+Ironic;–;–;✅;✅;–;–;–;–;–;–;–;–;"Ironic + Tenks; Prometheus on; DNSMasq/iSCSI helpers."
+IPv6;❌;–;✅;–;✅;–;–;–;–;–;–;–;"IPv6-only deployment; currently disabled (disk pressure)."
+Kayobe;–;–;–;–;–;–;–;–;–;–;–;–;Kayobe overcloud smoke (non-voting).
+KVM;–;–;–;✅;–;–;✅;–;–;–;–;–;Nested virt compute (KVM).
+Let's Encrypt;–;✅;✅;–;✅;–;✅;–;–;–;–;–;"Pebble ACME end-to-end, dashboard; DB/Rabbit TLS."
+Magnum;–;–;✅;–;–;–;–;–;–;–;–;–;Magnum + Designate + Trove.
+MariaDB;–;✅;–;✅;✅;–;✅;–;–;–;–;–;Galera + ProxySQL, Fluentd, HAProxy, Keepalived.
+Masakari;–;–;✅;–;–;–;–;–;–;–;–;✅;Masakari + Pacemaker.
+NFV;–;–;✅;–;✅;–;–;–;–;–;✅;✅;Tacker + Neutron SFC, Barbican, Mistral, Aodh.
+Octavia;–;–;✅;–;–;–;–;–;✅;✅;–;–;Octavia/Amphora.
+OpenBao;–;–;–;–;–;–;–;–;–;–;–;–;"OpenBao-backed password management (password round-trip only; no deploy)."
+OVN;–;✅;✅;✅;✅;–;✅;✅;–;✅;–;–;Neutron ML2/OVN + OVN Octavia provider.
+Prometheus + OpenSearch;–;–;–;✅;–;✅;✅;–;–;–;–;–;Fluentd, OpenSearch, Grafana, Prometheus, RabbitMQ/DB core.
+Skyline;❌;–;✅;–;–;✅;–;–;–;–;–;–;"Skyline dashboard; currently disabled (SSO issues)."
+Telemetry;–;–;✅;–;–;✅;–;–;–;–;✅;✅;Aodh, Ceilometer, Gnocchi.
diff --git a/doc/source/contributor/ci.rst b/doc/source/contributor/ci.rst index 71f9e3032..0ffd7d498 100644 --- a/doc/source/contributor/ci.rst +++ b/doc/source/contributor/ci.rst @@ -28,3 +28,21 @@ consumes a large amount of logging resources. Please note that git usually strips lines beginning with `#` from the commit message. This can be avoided by preceding the string with a space. + +CI coverage matrix +~~~~~~~~~~~~~~~~~~ + +Zuul job templates live in ``zuul.d`` and are applied in +``zuul.d/project.yaml``. Pipelines always run tox/python style+unit checks, +docs/release builds, and requirements checks; the matrix below shows the +scenario jobs in ``check``/``gate``. + +.. csv-table:: Scenario matrix + :header-rows: 1 + :file: ci-matrix.csv + :widths: 12 7 7 7 7 7 7 7 7 7 7 7 7 12 + :delim: ; + +Legend: ✅ = covered, ❌ = disabled, – = not covered. ``Core`` means the standard +Keystone/Glance/Neutron/Nova/Heat stack is deployed; ``Tempest`` indicates +smoke tests run; ``SLURP`` = Skip Level Upgrade Release Process. diff --git a/doc/source/contributor/contributing.rst b/doc/source/contributor/contributing.rst index 0fe6c4abf..7e9bff16a 100644 --- a/doc/source/contributor/contributing.rst +++ b/doc/source/contributor/contributing.rst @@ -46,55 +46,23 @@ Whiteboard (etherpad) Contacting the Core Team ~~~~~~~~~~~~~~~~~~~~~~~~ -The list in alphabetical order (on first name): - -+-----------------------+---------------+------------------------------------+ -| Name | IRC nick | Email address | -+=======================+===============+====================================+ -| `Chason Chan`_ | chason | chason.chan@foxmail.com | -+-----------------------+---------------+------------------------------------+ -| `Christian Berendt`_ | berendt | berendt@betacloud-solutions.de | -+-----------------------+---------------+------------------------------------+ -| `Dincer Celik`_ | osmanlicilegi | hello@dincercelik.com | -+-----------------------+---------------+------------------------------------+ -| `Eduardo Gonzalez`_ | egonzalez | dabarren@gmail.com | -+-----------------------+---------------+------------------------------------+ -| `Jeffrey Zhang`_ | Jeffrey4l | jeffrey.zhang@99cloud.net | -+-----------------------+---------------+------------------------------------+ -| `Marcin Juszkiewicz`_ | hrw | marcin.juszkiewicz@linaro.org | -+-----------------------+---------------+------------------------------------+ -| `Mark Goddard`_ | mgoddard | mark@stackhpc.com | -+-----------------------+---------------+------------------------------------+ -| `Michał Nasiadka`_ | mnasiadka | mnasiadka@gmail.com | -+-----------------------+---------------+------------------------------------+ -| `Radosław Piliszek`_ | yoctozepto | radoslaw.piliszek@gmail.com | -+-----------------------+---------------+------------------------------------+ -| `Surya Prakash`_ | spsurya | singh.surya64mnnit@gmail.com | -+-----------------------+---------------+------------------------------------+ -| `Cao Yuan`_ | caoyuan | cao.yuan@99cloud.net | -+-----------------------+---------------+------------------------------------+ - -.. _Chason Chan: https://launchpad.net/~chen-xing -.. _Christian Berendt: https://launchpad.net/~berendt -.. _Dincer Celik: https://launchpad.net/~osmanlicilegi -.. _Eduardo Gonzalez: https://launchpad.net/~egonzalez90 -.. _Jeffrey Zhang: https://launchpad.net/~jeffrey4l -.. _Marcin Juszkiewicz: https://launchpad.net/~hrw -.. _Mark Goddard: https://launchpad.net/~mgoddard -.. _Michał Nasiadka: https://launchpad.net/~mnasiadka -.. _Radosław Piliszek: https://launchpad.net/~yoctozepto -.. _Surya Prakash: https://launchpad.net/~confisurya -.. _Cao Yuan: https://launchpad.net/~caoi-yuan - -The current effective list is also available from Gerrit: -https://review.opendev.org/#/admin/groups/1637,members +In general it is suggested to use the above mentioned public communication +channels, but if you find that you need to contact someone from the Core team +directly, you can find the lists in Gerrit: + +- kolla-core https://review.opendev.org/admin/groups/28d5dccfccc125b3963f76ab67e256501565d52b,members +- kayobe-core https://review.opendev.org/admin/groups/361e28280e3a06be2997a5aa47a8a11d3a8fb9b9,members New Feature Planning ~~~~~~~~~~~~~~~~~~~~ -New features are discussed via IRC or mailing list (with [kolla] prefix). -Kolla project keeps blueprints in `Launchpad <https://blueprints.launchpad.net/kolla-ansible>`__. -Specs are welcome but not strictly required. +New features are discussed via IRC or on the openstack-discuss mailing list +(please include the [kolla] prefix to your subject line). + +Kolla has previously used Launchpad blueprints, but now simply uses tracking +bugs for new feature work. Please tag any such bugs with a "[RFE]" prefix, +which indicates the bug is a Request For Enhancement. Bugs are discussed in +more detail in the next section. Task Tracking ~~~~~~~~~~~~~ diff --git a/doc/source/contributor/release-notes.rst b/doc/source/contributor/release-notes.rst index fb48c06e8..766c64a39 100644 --- a/doc/source/contributor/release-notes.rst +++ b/doc/source/contributor/release-notes.rst @@ -9,22 +9,25 @@ Introduction Kolla Ansible (just like Kolla) uses the following release notes sections: -- ``features`` --- for new features or functionality; these should ideally +* ``features`` --- for new features or functionality; these should ideally refer to the blueprint being implemented; -- ``fixes`` --- for fixes closing bugs; these must refer to the bug being +* ``fixes`` --- for fixes closing bugs; these must refer to the bug being closed; -- ``upgrade`` --- for notes relevant when upgrading from previous version; +* ``upgrade`` --- for notes relevant when upgrading from previous version; these should ideally be added only between major versions; required when the proposed change affects behaviour in a non-backwards compatible way or generally changes something impactful; -- ``deprecations`` --- to track deprecated features; relevant changes may +* ``deprecations`` --- to track deprecated features; relevant changes may consist of only the commit message and the release note; -- ``prelude`` --- filled in by the PTL before each release or RC. +* ``prelude`` --- filled in by the PTL before each release or RC. Other release note types may be applied per common sense. -Each change should include a release note unless being a ``TrivialFix`` -change or affecting only docs or CI. Such changes should `not` include -a release note to avoid confusion. + +When a release note is required: + +- ``feature`` - best included with docs change (if separate from the code) +- ``user impacting`` - to improve visibility of the change for users + Remember release notes are mostly for end users which, in case of Kolla, are OpenStack administrators/operators. In case of doubt, the core team will let you know what is required. diff --git a/doc/source/contributor/setup-identity-provider.rst b/doc/source/contributor/setup-identity-provider.rst index 99e5ae780..6e2b8a0ed 100644 --- a/doc/source/contributor/setup-identity-provider.rst +++ b/doc/source/contributor/setup-identity-provider.rst @@ -45,14 +45,14 @@ if you want to use any other realm name, you must to change 'new_realm' in the URIs used in the guide and replace the 'new_realm' with the realm name that you are using. -- Access the admin console on http://localhost:8080/auth/ in the Administration Console option. -- Authenticate using the credentials defined in the creation step. -- Create a new realm in the http://localhost:8080/auth/admin/master/console/#/create/realm page. -- After creating a realm, you will need to create a client to be used by Keystone; to do it, just access http://localhost:8080/auth/admin/master/console/#/create/client/new_realm. -- To create a client, you will need to set the client_id (just choose anyone), +* Access the admin console on http://localhost:8080/auth/ in the Administration Console option. +* Authenticate using the credentials defined in the creation step. +* Create a new realm in the http://localhost:8080/auth/admin/master/console/#/create/realm page. +* After creating a realm, you will need to create a client to be used by Keystone; to do it, just access http://localhost:8080/auth/admin/master/console/#/create/client/new_realm. +* To create a client, you will need to set the client_id (just choose anyone), the protocol (must be openid-connect) and the Root Url (you can leave it blank) -- After creating the client, you will need to update some client's attributes +* After creating the client, you will need to update some client's attributes like: - Enable the Implicit flow (this one allows you to use the OpenStack CLI with @@ -72,12 +72,12 @@ are using. openstack-default-project user attribute ==================================== ============== -- After creating the client, you will need to create a user in that realm to +* After creating the client, you will need to create a user in that realm to log in OpenStack via identity federation -- To create a user, access http://localhost:8080/auth/admin/master/console/#/create/user/new_realm and fill the form with the user's data -- After creating the user, you can access the tab "Credentials" to set the +* To create a user, access http://localhost:8080/auth/admin/master/console/#/create/user/new_realm and fill the form with the user's data +* After creating the user, you can access the tab "Credentials" to set the user's password -- Then, in the tab "Attributes", you must set the authorization attributes to +* Then, in the tab "Attributes", you must set the authorization attributes to be used by Keystone, these attributes are defined in the :ref:`attribute mapping <attribute_mapping>` in Keystone @@ -90,10 +90,10 @@ Configuring Kolla Ansible to use the Identity Provider This section is about how one can get the data needed in :ref:`Setup OIDC via Kolla Ansible <setup-oidc-kolla-ansible>`. -- name: The realm name, in this case it will be "new_realm" -- identifier: http://localhost:8080/auth/realms/new_realm/ (again, the "new_realm" is the name of the realm) -- certificate_file: This one can be downloaded from http://localhost:8080/auth/admin/master/console/#/realms/new_realm/keys -- metadata_folder: +* name: The realm name, in this case it will be "new_realm" +* identifier: http://localhost:8080/auth/realms/new_realm/ (again, the "new_realm" is the name of the realm) +* certificate_file: This one can be downloaded from http://localhost:8080/auth/admin/master/console/#/realms/new_realm/keys +* metadata_folder: - localhost%3A8080%2Fauth%2Frealms%2Fnew_realm.client: diff --git a/doc/source/reference/bare-metal/ironic-guide.rst b/doc/source/reference/bare-metal/ironic-guide.rst index 62fc93673..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: @@ -26,7 +26,7 @@ define a network to be used for the Ironic cleaning network: ironic_dnsmasq_interface: "eth1" ironic_cleaning_network: "public1" -Finally, define at least one DHCP range for Ironic inspector: +Finally, define at least one DHCP range for Ironic inspection: .. code-block:: yaml @@ -52,6 +52,16 @@ For example it can be the same address as default router for the range: routers: "192.168.5.1" ntp_server: "192.168.5.1" +Provide a DNS server if the inspection ramdisk (IPA) needs to resolve +Fully Qualified Domain Names (FQDNs) for API access. To specify multiple +servers, use a comma-separated list. + +.. code-block:: yaml + + ironic_dnsmasq_dhcp_ranges: + - range: "192.168.5.100,192.168.5.110" + dns_servers: "192.168.5.10,192.168.5.11" + To support DHCP relay, it is also possible to define a netmask in the range. It is advisable to also provide a router to allow the traffic to reach the Ironic server. @@ -76,7 +86,7 @@ The default lease time for each range can be configured globally via ``ironic_dnsmasq_dhcp_default_lease_time`` variable or per range via ``lease_time`` parameter. -In the same file, specify the PXE bootloader file for Ironic Inspector. The +In the same file, specify the PXE bootloader file for Ironic inspection. The file is relative to the ``/var/lib/ironic/tftpboot`` directory. The default is ``pxelinux.0``, and should be correct for x86 systems. Other platforms may require a different value, for example aarch64 on Debian requires @@ -86,7 +96,7 @@ require a different value, for example aarch64 on Debian requires ironic_dnsmasq_boot_file: pxelinux.0 -Ironic inspector also requires a deploy kernel and ramdisk to be placed in +Ironic inspection also requires a deploy kernel and ramdisk to be placed in ``/etc/kolla/config/ironic/``. The following example uses coreos which is commonly used in Ironic deployments, though any compatible kernel/ramdisk may be used: @@ -103,10 +113,30 @@ You may optionally pass extra kernel parameters to the inspection kernel using: .. code-block:: yaml - ironic_inspector_kernel_cmdline_extras: ['ipa-lldp-timeout=90.0', 'ipa-collect-lldp=1'] + ironic_kernel_cmdline_extras: ['ipa-lldp-timeout=90.0', 'ipa-collect-lldp=1'] in ``/etc/kolla/globals.yml``. +PXE filter (optional) +~~~~~~~~~~~~~~~~~~~~~ + +To keep parity with the standalone inspector you can enable the experimental +PXE filter service: + +.. code-block:: yaml + + 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 +the dnsmasq DHCP range overlaps with a Neutron-served network. For the upstream +details see +https://docs.openstack.org/ironic/latest/admin/inspection/pxe_filter.html. + +.. note:: + + Upstream still classifies this PXE filter implementation as experimental. + Configure conductor's HTTP server port (optional) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The port used for conductor's HTTP server is controlled via @@ -116,11 +146,27 @@ The port used for conductor's HTTP server is controlled via ironic_http_port: "8089" +Configure Ironic Python Agent NTP server (optional) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The Ironic Python Agent requires that the system clock is set correctly for +the heartbeat mechanism to work. One way of achieving this is to pass +the address of an NTP server via the kernel commandline, which is then +used to set the system clock when IPA first starts. This is not a hard +requirement, and you may use other methods. For example DHCP, or functionality +built into the BMC. + +If you wish to use this option you can set ``ironic_ntp_server`` in +``/etc/kolla/globals.yml``. Eg. + +.. code-block:: yaml + + ironic_ntp_server: "192.168.33.3" + Revert to plain PXE (not recommended) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Starting with Yoga, Ironic has changed the default PXE from plain PXE to iPXE. Kolla Ansible follows this upstream decision by choosing iPXE as the default -for Ironic Inspector but allows users to revert to the previous default of +for Ironic inspection but allows users to revert to the previous default of plain PXE by setting the following in ``/etc/kolla/globals.yml``: @@ -143,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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -215,7 +261,7 @@ Post-deployment configuration The :ironic-doc:`Ironic documentation <install/configure-glance-images>` describes how to create the deploy kernel and ramdisk and register them with Glance. In this example we're reusing the same images that were fetched for the -Inspector: +inspection: .. code-block:: console diff --git a/doc/source/reference/compute/index.rst b/doc/source/reference/compute/index.rst index 822f09b27..b13bd2ec9 100644 --- a/doc/source/reference/compute/index.rst +++ b/doc/source/reference/compute/index.rst @@ -13,5 +13,3 @@ compute services. nova-cells-guide nova-fake-driver nova-guide - vmware-guide - zun-guide diff --git a/doc/source/reference/compute/libvirt-guide.rst b/doc/source/reference/compute/libvirt-guide.rst index e226d2fe3..24a55e1fb 100644 --- a/doc/source/reference/compute/libvirt-guide.rst +++ b/doc/source/reference/compute/libvirt-guide.rst @@ -157,8 +157,8 @@ information: Kolla Ansible will search for these files for each compute node in the following locations and order on the host where Kolla Ansible is executed: -- ``/etc/kolla/config/nova/nova-libvirt/<hostname>/`` -- ``/etc/kolla/config/nova/nova-libvirt/`` +* ``/etc/kolla/config/nova/nova-libvirt/<hostname>/`` +* ``/etc/kolla/config/nova/nova-libvirt/`` In most cases you will want to have a unique set of server and client certificates and keys per hypervisor and with a common CA certificate. In this 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 464e84abd..1069030bb 100644 --- a/doc/source/reference/compute/nova-guide.rst +++ b/doc/source/reference/compute/nova-guide.rst @@ -7,13 +7,13 @@ 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 ====================== The virtualisation driver may be selected via ``nova_compute_virt_type`` in -``globals.yml``. Supported options are ``qemu``, ``kvm``, and ``vmware``. +``globals.yml``. Supported options are ``qemu`` and ``kvm``. The default is ``kvm``. Libvirt @@ -22,12 +22,6 @@ Libvirt Information on the libvirt-based drivers ``kvm`` and ``qemu`` can be found in :doc:`libvirt-guide`. -VMware ------- - -Information on the VMware-based driver ``vmware`` can be found in -:doc:`vmware-guide`. - Bare Metal ---------- @@ -49,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 ===== @@ -127,3 +136,13 @@ effectively remove the configuration when the Nova Compute service is restarted. If you choose to undefine `nova_cell_compute_provider_config` on a host, you must manually remove the generated config from inside the container, or recreate the container. + +Emulated virtual Trusted Platform Module (vTPM) +=============================================== + +Nova supports adding an emulated virtual Trusted Platform Module (vTPM) to +instances. This feature is implemented with the SWTPM (Software TPM Emulator) +package. To enable this feature, set ``enable_nova_swtpm`` to ``true``. +Beware of `limitations`__ that come with this solution. + + __ https://docs.openstack.org/nova/latest/admin/emulated-tpm.html#limitations diff --git a/doc/source/reference/compute/vmware-guide.rst b/doc/source/reference/compute/vmware-guide.rst deleted file mode 100644 index a2b6540eb..000000000 --- a/doc/source/reference/compute/vmware-guide.rst +++ /dev/null @@ -1,488 +0,0 @@ -.. _vmware-guide: - -=================================== -VMware - Nova Virtualisation Driver -=================================== - -Overview -~~~~~~~~ - -Kolla can deploy the Nova and Neutron Service(s) for VMware vSphere. -Depending on the network architecture (NsxT, NsxV or DVS) you choose, -Kolla deploys the following OpenStack services for VMware vSphere: - -For VMware NsxT: - -* nova-compute -* neutron-server - -For VMware NsxV: - -* nova-compute -* neutron-server - -For VMware DVS: - -* nova-compute -* neutron-server -* neutron-dhcp-agent -* neutron-metadata-agent - -Kolla can deploy the Glance and Cinder services using VMware datastore as their -backend. -You can create Cinder volumes as VMDKs or as First Class Disks (FCDs). - -An FCD, also known as an Improved Virtual Disk (IVD) or Managed Virtual Disk, -is a named virtual disk independent of a virtual machine. -Using FCDs for Cinder volumes eliminates the need for shadow virtual machines. - -The FCD backend is offered in addition to the default VMDK backend. -If you use FCD as the backend driver for Cinder, you can use both FCD and -VMDK volumes in the same deployment. - -Ceilometer metering for vSphere is also supported. - -Because the `vmware-nsx <https://github.com/openstack/vmware-nsx>`__ drivers for -neutron use completely different architecture than other types of -virtualization, vmware-nsx drivers cannot coexist with other type -of virtualization in one region. In neutron vmware-nsx drivers, -neutron-server acts like an agent to translate OpenStack actions -into what vSphere/NSX Manager API can understand. Neutron does -not directly takes control of the Open vSwitch inside the VMware -environment but through the API exposed by vSphere/NSX Manager. - -.. note:: - - VMware NSX plugin is not in the kolla image by default. - VMware NSX plugin has to be added in the neutron image and - if you are using vmware_dvs also in neutron-dhcp-agent image. - -For VMware DVS, the Neutron DHCP agent does not attaches to Open vSwitch inside -VMware environment, but attach to the Open vSwitch bridge called ``br-dvs`` on -the OpenStack side and replies to/receives DHCP packets through VLAN. Similar -to what the DHCP agent does, Neutron metadata agent attaches to ``br-dvs`` -bridge and works through VLAN. - -.. note:: - - VMware NSX-DVS plugin does not support tenant networks, so all VMs should - attach to Provider VLAN/Flat networks. - -VMware NSX-T -~~~~~~~~~~~~ - -Preparation ------------ - -You should have a working NSX-T environment, this part is out of scope -of Kolla. For more information, please see -`VMware NSX-T documentation <https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html/>`__. -The NSX Manager provides a web-based user interface where you can manage -your NSX-T environment. -It also hosts the API server that processes API calls. -The NSX Manager interface provides two modes for configuring resources: - -- Policy mode -- Manager mode - -In Kolla you will have the choice between both with neutron plugin -vmware_nsxv3 for Manager mode and vmware_nsxp for Policy Mode. -For more information, please see -`documentation <https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/installation/GUID-BB26CDC8-2A90-4C7E-9331-643D13FEEC4A.html/>`__. - ------------------------------------------------------------------------------- - -In addition, it is important to modify the firewall rule of vSphere to make -sure that VNC is accessible from outside VMware environment. - -On every VMware host, edit ``/etc/vmware/firewall/vnc.xml`` as below: - -.. code-block:: xml - - <!-- FirewallRule for VNC Console --> - <ConfigRoot> - <service> - <id>VNC</id> - <rule id = '0000'> - <direction>inbound</direction> - <protocol>tcp</protocol> - <porttype>dst</porttype> - <port> - <begin>5900</begin> - <end>5999</end> - </port> - </rule> - <rule id = '0001'> - <direction>outbound</direction> - <protocol>tcp</protocol> - <porttype>dst</porttype> - <port> - <begin>0</begin> - <end>65535</end> - </port> - </rule> - <enabled>true</enabled> - <required>false</required> - </service> - </ConfigRoot> - -Then refresh the firewall config by: - -.. code-block:: console - - # esxcli network firewall refresh - -Verify that the firewall config is applied: - -.. code-block:: console - - # esxcli network firewall ruleset list - ------------------------------------------------------------------------------- - -Deployment ----------- - -The deployment below covers the Policy mode (vmware_nsxp) - -Enable VMware nova-compute plugin and NSX-T neutron-server plugin in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_openvswitch: no - nova_compute_virt_type: "vmware" - neutron_plugin_agent: "vmware_nsxp" - -If you want to set VMware datastore as cinder backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_cinder: "yes" - cinder_backend_vmwarevc_vmdk: "yes" - vmware_datastore_name: "TestDatastore" - -If you want to set VMware First Class Disk (FCD) datastore -as VMware vStorage Object backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_cinder: "yes" - cinder_backend_vmware_vstorage_object: "yes" - vmware_datastore_name: "TestDatastore" - -If you want to set VMware datastore as glance backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - glance_backend_vmware: "yes" - vmware_vcenter_name: "TestDatacenter" - vmware_datastore_name: "TestDatastore" - -VMware options are required in ``/etc/kolla/globals.yml``, these options should -be configured correctly according to your NSX-T environment. - -Options for ``nova-compute`` and ``ceilometer``: - -.. code-block:: yaml - - vmware_vcenter_host_ip: "127.0.0.1" - vmware_vcenter_host_username: "admin" - vmware_vcenter_cluster_name: "cluster-1" - vmware_vcenter_insecure: "True" - vmware_vcenter_datastore_regex: ".*" - -.. note:: - - The VMware vCenter password has to be set in ``/etc/kolla/passwords.yml``. - - .. code-block:: yaml - - vmware_vcenter_host_password: "admin" - -Options for Neutron NSX-T support: - -.. code-block:: yaml - - vmware_nsxp_api_user: "admin" - vmware_nsxp_insecure: true - vmware_nsxp_default_tier0_router: "T0-Example" - vmware_nsxp_dhcp_profile: "dhcp-profile-example" - vmware_nsxp_metadata_proxy: "metadata_proxy-example" - vmware_nsxp_api_managers: "nsx-manager.local" - vmware_nsxp_default_vlan_tz: "vlan-tz-example" - vmware_nsxp_default_overlay_tz: "overlay-tz-example" - -.. yaml - -.. note:: - - If you want to set secure connections to VMware, set ``vmware_vcenter_insecure`` - to false. - Secure connections to vCenter requires a CA file, copy the vCenter CA file to - ``/etc/kolla/config/vmware_ca``. - -.. note:: - - The VMware NSX-T password has to be set in ``/etc/kolla/passwords.yml``. - - .. code-block:: yaml - - vmware_nsxp_api_password: "xxxxx" - vmware_nsxp_metadata_proxy_shared_secret: "xxxxx" - -Then you should start :command:`kolla-ansible` deployment normally as -KVM/QEMU deployment. - -VMware NSX-V -~~~~~~~~~~~~ - -Preparation ------------ - -You should have a working NSX-V environment, this part is out of scope -of Kolla. -For more information, please see -`VMware NSX-V documentation <https://docs.vmware.com/en/VMware-NSX-for-vSphere/>`__. - ------------------------------------------------------------------------------- - -In addition, it is important to modify the firewall rule of vSphere to make -sure that VNC is accessible from outside VMware environment. - -On every VMware host, edit ``/etc/vmware/firewall/vnc.xml`` as below: - -.. code-block:: xml - - <!-- FirewallRule for VNC Console --> - <ConfigRoot> - <service> - <id>VNC</id> - <rule id = '0000'> - <direction>inbound</direction> - <protocol>tcp</protocol> - <porttype>dst</porttype> - <port> - <begin>5900</begin> - <end>5999</end> - </port> - </rule> - <rule id = '0001'> - <direction>outbound</direction> - <protocol>tcp</protocol> - <porttype>dst</porttype> - <port> - <begin>0</begin> - <end>65535</end> - </port> - </rule> - <enabled>true</enabled> <required>false</required> - </service> - </ConfigRoot> - -Then refresh the firewall config by: - -.. code-block:: console - - # esxcli network firewall refresh - -Verify that the firewall config is applied: - -.. code-block:: console - - # esxcli network firewall ruleset list - ------------------------------------------------------------------------------- - -Deployment ----------- - -Enable VMware nova-compute plugin and NSX-V neutron-server plugin in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - nova_compute_virt_type: "vmware" - neutron_plugin_agent: "vmware_nsxv" - -.. note:: - - VMware NSX-V also supports Neutron FWaaS and VPNaaS services, you can enable - them by setting these options in ``globals.yml``: - - * enable_neutron_vpnaas: "yes" - * enable_neutron_fwaas: "yes" - -If you want to set VMware VMDK datastore as cinder backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_cinder: "yes" - cinder_backend_vmwarevc_vmdk: "yes" - vmware_datastore_name: "TestDatastore" - -If you want to set VMware First Class Disk (FCD) datastore -as VMware vStorage Object backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_cinder: "yes" - cinder_backend_vmware_vstorage_object: "yes" - vmware_datastore_name: "TestDatastore" - -If you want to set VMware datastore as glance backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - glance_backend_vmware: "yes" - vmware_vcenter_name: "TestDatacenter" - vmware_datastore_name: "TestDatastore" - -VMware options are required in ``/etc/kolla/globals.yml``, these options should -be configured correctly according to your NSX-V environment. - -Options for ``nova-compute`` and ``ceilometer``: - -.. code-block:: yaml - - vmware_vcenter_host_ip: "127.0.0.1" - vmware_vcenter_host_username: "admin" - vmware_vcenter_cluster_name: "cluster-1" - vmware_vcenter_insecure: "True" - vmware_vcenter_datastore_regex: ".*" - -.. note:: - - The VMware vCenter password has to be set in ``/etc/kolla/passwords.yml``. - - .. code-block:: yaml - - vmware_vcenter_host_password: "admin" - -Options for Neutron NSX-V support: - -.. code-block:: yaml - - vmware_nsxv_user: "nsx_manager_user" - vmware_nsxv_manager_uri: "https://127.0.0.1" - vmware_nsxv_cluster_moid: "TestCluster" - vmware_nsxv_datacenter_moid: "TestDataCeter" - vmware_nsxv_resource_pool_id: "TestRSGroup" - vmware_nsxv_datastore_id: "TestDataStore" - vmware_nsxv_external_network: "TestDVSPort-Ext" - vmware_nsxv_vdn_scope_id: "TestVDNScope" - vmware_nsxv_dvs_id: "TestDVS" - vmware_nsxv_backup_edge_pool: "service:compact:1:2" - vmware_nsxv_spoofguard_enabled: "false" - vmware_nsxv_metadata_initializer: "false" - vmware_nsxv_edge_ha: "false" - -.. yaml - -.. note:: - - If you want to set secure connections to VMware, set ``vmware_vcenter_insecure`` - to false. - Secure connections to vCenter requires a CA file, copy the vCenter CA file to - ``/etc/kolla/config/vmware_ca``. - -.. note:: - - The VMware NSX-V password has to be set in ``/etc/kolla/passwords.yml``. - - .. code-block:: yaml - - vmware_nsxv_password: "nsx_manager_password" - -Then you should start :command:`kolla-ansible` deployment normally as -KVM/QEMU deployment. - - -VMware NSX-DVS -~~~~~~~~~~~~~~ - -Preparation ------------ - -Before deployment, you should have a working VMware vSphere environment. -Create a cluster and a vSphere Distributed Switch with all the host in the -cluster attached to it. - -For more information, please see -`Setting Up Networking with vSphere Distributed Switches <http://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.networking.doc/GUID-375B45C7-684C-4C51-BA3C-70E48DFABF04.html>`__. - -Deployment ----------- - -Enable VMware nova-compute plugin and NSX-V neutron-server plugin in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - nova_compute_virt_type: "vmware" - neutron_plugin_agent: "vmware_dvs" - -If you want to set VMware VMDK datastore as cinder backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_cinder: "yes" - cinder_backend_vmwarevc_vmdk: "yes" - vmware_datastore_name: "TestDatastore" - -If you want to set VMware First Class Disk (FCD) datastore -as VMware vStorage Object backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - enable_cinder: "yes" - cinder_backend_vmware_vstorage_object: "yes" - vmware_datastore_name: "TestDatastore" - -If you want to set VMware datastore as Glance backend, enable it in -``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - glance_backend_vmware: "yes" - vmware_vcenter_name: "TestDatacenter" - vmware_datastore_name: "TestDatastore" - -VMware options are required in ``/etc/kolla/globals.yml``, these options should -be configured correctly according to the vSphere environment you installed -before. All option for nova, cinder, glance are the same as VMware-NSX, except -the following options. - -Options for Neutron NSX-DVS support: - -.. code-block:: yaml - - vmware_dvs_host_ip: "192.168.1.1" - vmware_dvs_host_port: "443" - vmware_dvs_host_username: "admin" - vmware_dvs_dvs_name: "VDS-1" - vmware_dvs_dhcp_override_mac: "" - -.. note:: - - The VMware NSX-DVS password has to be set in ``/etc/kolla/passwords.yml``. - - .. code-block:: yaml - - vmware_dvs_host_password: "password" - -Then you should start :command:`kolla-ansible` deployment normally as -KVM/QEMU deployment. - -For more information on OpenStack vSphere, see -:nova-doc:`VMware vSphere -<admin/configuration/hypervisor-vmware.html>`, -`VMware-NSX package <https://github.com/openstack/vmware-nsx>`_. diff --git a/doc/source/reference/compute/zun-guide.rst b/doc/source/reference/compute/zun-guide.rst deleted file mode 100644 index 9959dede1..000000000 --- a/doc/source/reference/compute/zun-guide.rst +++ /dev/null @@ -1,116 +0,0 @@ -======================= -Zun - Container service -======================= - -"Zun is an OpenStack Container service. It aims to provide an -OpenStack API for provisioning and managing containerized -workload on OpenStack." -For more details about Zun, see `OpenStack Zun Documentation -<https://docs.openstack.org/zun/latest/>`__. - -Preparation and Deployment --------------------------- - -By default Zun and its dependencies are disabled. -In order to enable Zun, you need to edit globals.yml and set the -following variables: - -.. code-block:: yaml - - enable_zun: "yes" - enable_kuryr: "yes" - enable_etcd: "yes" - docker_configure_for_zun: "yes" - containerd_configure_for_zun: "yes" - -Docker reconfiguration requires rebootstrapping before deploy. -Make sure you understand the consequences of restarting Docker. -Please see :ref:`rebootstrapping` for details. -If it's initial deploy, then there is nothing to worry about -because it's initial bootstrapping as well and there are no -running services to affect. - -.. code-block:: console - - $ kolla-ansible bootstrap-servers - -Finally deploy: - -.. code-block:: console - - $ kolla-ansible deploy - -Verification ------------- - -#. Generate the credentials file: - - .. code-block:: console - - $ kolla-ansible post-deploy - -#. Source credentials file: - - .. code-block:: console - - $ . /etc/kolla/admin-openrc.sh - -#. Download and create a glance container image: - - .. code-block:: console - - $ docker pull cirros - $ docker save cirros | openstack image create cirros --public \ - --container-format docker --disk-format raw - -#. Create zun container: - - .. code-block:: console - - $ zun create --name test --net network=demo-net cirros ping -c4 8.8.8.8 - - .. note:: - - Kuryr does not support networks with DHCP enabled, disable DHCP in the - subnet used for zun containers. - - .. code-block:: console - - $ openstack subnet set --no-dhcp <subnet> - -#. Verify container is created: - - .. code-block:: console - - $ zun list - - +--------------------------------------+------+---------------+---------+------------+------------+-------+ - | uuid | name | image | status | task_state | addresses | ports | - +--------------------------------------+------+---------------+---------+------------+------------+-------+ - | 3719a73e-5f86-47e1-bc5f-f4074fc749f2 | test | cirros | Created | None | 172.17.0.3 | [] | - +--------------------------------------+------+---------------+---------+------------+------------+-------+ - -#. Start container: - - .. code-block:: console - - $ zun start test - Request to start container test has been accepted. - -#. Verify container: - - .. code-block:: console - - $ zun logs test - PING 8.8.8.8 (8.8.8.8): 56 data bytes - 64 bytes from 8.8.8.8: seq=0 ttl=45 time=96.396 ms - 64 bytes from 8.8.8.8: seq=1 ttl=45 time=96.504 ms - 64 bytes from 8.8.8.8: seq=2 ttl=45 time=96.721 ms - 64 bytes from 8.8.8.8: seq=3 ttl=45 time=95.884 ms - - --- 8.8.8.8 ping statistics --- - 4 packets transmitted, 4 packets received, 0% packet loss - round-trip min/avg/max = 95.884/96.376/96.721 ms - -For more information about how zun works, see -`zun, OpenStack Container service <https://docs.openstack.org/zun/latest/>`__. diff --git a/doc/source/reference/containers/index.rst b/doc/source/reference/containers/index.rst index c1bcc84d4..76afa71f8 100644 --- a/doc/source/reference/containers/index.rst +++ b/doc/source/reference/containers/index.rst @@ -2,11 +2,9 @@ Containers ========== -This section describes configuring and running container based services -including kuryr. +This section describes configuring and running container based services. .. toctree:: :maxdepth: 1 - kuryr-guide magnum-guide diff --git a/doc/source/reference/containers/kuryr-guide.rst b/doc/source/reference/containers/kuryr-guide.rst deleted file mode 100644 index fbcbfd419..000000000 --- a/doc/source/reference/containers/kuryr-guide.rst +++ /dev/null @@ -1,65 +0,0 @@ -============================ -Kuryr - Container networking -============================ - -"Kuryr is a Docker network plugin that uses Neutron to provide networking -services to Docker containers. It provides containerized images for the common -Neutron plugins. Kuryr requires at least Keystone and neutron. Kolla makes -kuryr deployment faster and accessible. - -Requirements -~~~~~~~~~~~~ - -* A minimum of 3 hosts for a vanilla deploy - -Preparation and Deployment -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To allow Docker daemon connect to the etcd, add the following in the -``docker.service`` file. - -.. code-block:: ini - - ExecStart= -H tcp://172.16.1.13:2375 -H unix:///var/run/docker.sock --cluster-advertise=172.16.1.13:2375 - -The IP address is host running the etcd service. ```2375``` is port that -allows Docker daemon to be accessed remotely. ```2379``` is the etcd listening -port. - -By default etcd and kuryr are disabled in the ``group_vars/all.yml``. -In order to enable them, you need to edit the file globals.yml and set the -following variables - -.. code-block:: yaml - - enable_etcd: "yes" - enable_kuryr: "yes" - -Deploy the OpenStack cloud and kuryr network plugin - -.. code-block:: console - - kolla-ansible deploy - -Create a Virtual Network -~~~~~~~~~~~~~~~~~~~~~~~~ - -.. code-block:: console - - docker network create -d kuryr --ipam-driver=kuryr --subnet=10.1.0.0/24 --gateway=10.1.0.1 docker-net1 - -To list the created network: - -.. code-block:: console - - docker network ls - -The created network is also available from OpenStack CLI: - -.. code-block:: console - - openstack network list - -For more information about how kuryr works, see -`kuryr (OpenStack Containers Networking) -<https://docs.openstack.org/kuryr/latest/>`__. 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 71b51f77c..b09ab11b6 100644 --- a/doc/source/reference/databases/mariadb-guide.rst +++ b/doc/source/reference/databases/mariadb-guide.rst @@ -22,7 +22,7 @@ an independent Galera cluster. This section explains how to configure multiple database shards. Currently, only one shard is accessible via the HAProxy load balancer and supported -by the ``kolla-ansible mariadb_backup`` command. This will be improved +by the ``kolla-ansible mariadb-backup`` command. This will be improved in future by using ProxySQL, allowing load balanced access to all shards. Deployment @@ -52,9 +52,9 @@ inventory file in the way described below: .. note:: If ``mariadb_shard_id`` is not defined for host in inventory file it will be set automatically - to ``mariadb_default_database_shard_id`` (default 0) from ``group_vars/all.yml`` and can be - overwritten in ``/etc/kolla/globals.yml``. Shard which is marked as default is special in case - of backup or loadbalance, as it is described below. + to ``mariadb_default_database_shard_id`` (default 0) from ``group_vars/all/mariadb.yml`` and + can be overwritten in ``/etc/kolla/globals.yml``. Shard which is marked as default is + special in case of backup or loadbalance, as it is described below. Loadbalancer ------------ @@ -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 edfdc845d..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 ~~~~~~~~~~ @@ -44,9 +44,9 @@ retention policy is applied to all indices which match the and then eventually deletes them. It can be customised via the following variables: -- ``opensearch_apply_log_retention_policy`` -- ``opensearch_soft_retention_period_days`` -- ``opensearch_hard_retention_period_days`` +* ``opensearch_apply_log_retention_policy`` +* ``opensearch_soft_retention_period_days`` +* ``opensearch_hard_retention_period_days`` By default the soft and hard retention periods are 30 and 60 days respectively. If you are upgrading from ElasticSearch, and have previously diff --git a/doc/source/reference/logging-and-monitoring/grafana-guide.rst b/doc/source/reference/logging-and-monitoring/grafana-guide.rst index 12f123a20..412ca88e1 100644 --- a/doc/source/reference/logging-and-monitoring/grafana-guide.rst +++ b/doc/source/reference/logging-and-monitoring/grafana-guide.rst @@ -9,7 +9,7 @@ Overview `Grafana <https://grafana.com>`_ is open and composable observability and data visualization platform. Visualize metrics, logs, and traces from -multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, +multiple sources like Prometheus, Loki, Elasticsearch, Postgres and many more.. Preparation and deployment @@ -20,16 +20,65 @@ 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. +LDAP Authentication +~~~~~~~~~~~~~~~~~~~ + +Grafana can be configured to use LDAP for user authentication. To enable this +feature, set the following variable in ``/etc/kolla/globals.yml``: + +.. code-block:: yaml + + grafana_ldap_enabled: true + +The configuration for the LDAP server should be provided in a ``ldap.toml`` +file placed in the ``{{ node_custom_config }}/grafana/`` folder on the control +host. + +Example ``ldap.toml`` configuration: + +.. code-block:: ini + + [[servers]] + host = "openstack.org" + port = 389 + use_ssl = false + start_tls = true + + bind_dn = "CN=svc-openstack-grafana,OU=serviceaccounts,DC=openstack,DC=org" + bind_password = "strong_password" + + search_filter = "(sAMAccountName=%s)" + search_base_dns = ["OU=Users,DC=openstack,DC=org"] + + [servers.attributes] + name = "givenName" + surname = "sn" + username = "uid" + member_of = "memberOf" + email = "mail" + + [[servers.group_mappings]] + group_dn = "cn=grafana-admins,ou=groups,dc=openstack,dc=org" + org_role = "Admin" + + [[servers.group_mappings]] + group_dn = "cn=grafana-editors,ou=groups,dc=openstack,dc=org" + org_role = "Editor" + + [[servers.group_mappings]] + group_dn = "*" + org_role = "Viewer" + Custom dashboards provisioning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/reference/logging-and-monitoring/index.rst b/doc/source/reference/logging-and-monitoring/index.rst index 09d017547..05d0b96b7 100644 --- a/doc/source/reference/logging-and-monitoring/index.rst +++ b/doc/source/reference/logging-and-monitoring/index.rst @@ -10,6 +10,5 @@ logging and monitoring services available in kolla. central-logging-guide grafana-guide - influxdb-guide osprofiler-guide prometheus-guide diff --git a/doc/source/reference/logging-and-monitoring/influxdb-guide.rst b/doc/source/reference/logging-and-monitoring/influxdb-guide.rst deleted file mode 100644 index 6bb460d0c..000000000 --- a/doc/source/reference/logging-and-monitoring/influxdb-guide.rst +++ /dev/null @@ -1,28 +0,0 @@ -.. _influxdb-guide: - -=============================== -InfluxDB - Time Series Database -=============================== - -Overview -~~~~~~~~ - -InfluxDB is a time series database developed by InfluxData. It is -possible to deploy a single instance without charge. To use the -clustering features you will require a commercial license. - -InfluxDB -~~~~~~~~ - -The `recommendation <https://docs.influxdata.com/influxdb/v1.7/guides/hardware_sizing/#what-kind-of-storage-do-i-need>`_ -is to use flash storage for InfluxDB. If docker is configured to use -spinning disks by default, or you have some higher performance drives -available, it may be desirable to control where the docker volume is -located. This can be achieved by setting a path for -``influxdb_datadir_volume`` in ``/etc/kolla/globals.yml``: - -.. code-block:: yaml - - influxdb_datadir_volume: /mnt/ssd/influxdb/ - -The default is to use a named volume, ``influxdb``. 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 c8fc066ec..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: @@ -132,7 +132,7 @@ configure `ipmi_exporter <https://github.com/soundcloud/ipmi_exporter>`_, using the default value for ``node_custom_config``, you could create the following files: -- ``/etc/kolla/config/prometheus/prometheus.yml.d/ipmi-exporter.yml``: +* ``/etc/kolla/config/prometheus/prometheus.yml.d/ipmi-exporter.yml``: .. code-block:: jinja @@ -171,7 +171,7 @@ files: where ``ipmi_exporter_listen_address`` is a variable containing the IP address of the node where the exporter is running. -- ``/etc/kolla/config/prometheus/extras/file_sd/ipmi-exporter-targets.yml``: +* ``/etc/kolla/config/prometheus/extras/file_sd/ipmi-exporter-targets.yml``: .. code-block:: yaml @@ -239,7 +239,7 @@ For example: :caption: ``/etc/kolla/globals.yml`` prometheus_node_exporter_targets_extra: - - target: http://10.0.0.1:1234 + - target: 10.0.0.1:1234 labels: instance: host1 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/message-queues/rabbitmq.rst b/doc/source/reference/message-queues/rabbitmq.rst index 78983633e..139697633 100644 --- a/doc/source/reference/message-queues/rabbitmq.rst +++ b/doc/source/reference/message-queues/rabbitmq.rst @@ -23,7 +23,6 @@ Encryption of the following channels is not currently supported: * RabbitMQ cluster traffic between RabbitMQ server nodes * RabbitMQ CLI communication with RabbitMQ server nodes -* RabbitMQ Management API and UI (backend connection from HAProxy to RabbitMQ) Client-server ------------- @@ -126,18 +125,19 @@ different type, the follow procedure will be needed. release, following procedure is required to be carried out before any upgrade to Epoxy. -1. Stop all OpenStack services which use RabbitMQ, so that they will not - attempt to recreate any queues yet. +1. Generate the new config for all services. After this, make sure not to + restart any containers until after the RabbitMQ state has been reset. .. code-block:: console - kolla-ansible stop --tags <service-tags> + kolla-ansible genconfig -2. Generate the new config for all services. +2. Stop all OpenStack services which use RabbitMQ, so that they will not + attempt to recreate any queues yet. .. code-block:: console - kolla-ansible genconfig + kolla-ansible stop --tags <service-tags> 3. Reconfigure RabbitMQ if you were previously using ``om_enable_rabbitmq_high_availability``. @@ -160,54 +160,83 @@ different type, the follow procedure will be needed. kolla-ansible deploy --tags <service-tags> -SLURP -~~~~~ - -.. note:: - The version of RabbitMQ did not increase in Dalmatian, so this will not be - needed for a skip-level upgrade to Epoxy. +Upgrading RabbitMQ +~~~~~~~~~~~~~~~~~~ -RabbitMQ has two major version releases per year but does not support jumping -two versions in one upgrade. So if you want to perform a skip-level upgrade, -you must first upgrade RabbitMQ to an intermediary version. To do this, Kolla -provides multiple RabbitMQ versions in the odd OpenStack releases. To use the -upgrade from Antelope to Caracal as an example, we start on RabbitMQ version -3.11. In Antelope, you should upgrade to RabbitMQ version 3.12 with the command -below. You can then proceed with the usual SLURP upgrade to Caracal (and -therefore RabbitMQ version 3.13). - -.. warning:: +RabbitMQ upgrades in Kolla Ansible are typically restricted to a single minor +version increment at a time (e.g., from 4.0.x to 4.1.x). This is a safety +measure to ensure that RabbitMQ's internal data migrations and feature flags +are processed correctly. - This command should be run from the Antelope release. +In some cases, specific multi-version upgrade paths are supported (for example, +jumping from 3.13 directly to 4.2). These allowed paths are defined +using the ``rabbitmq_allowed_upgrades`` variable in the RabbitMQ role defaults. - Note that this command is NOT idempotent. See "RabbitMQ versions" below for - an alternative approach. - -.. code-block:: console - - kolla-ansible rabbitmq-upgrade 3.12 - -RabbitMQ versions -~~~~~~~~~~~~~~~~~ - -Alternatively, you can set ``rabbitmq_image`` in your configuration -``globals.yml`` for idempotence in deployments. As an example, Kolla ships -versions 3.11, 3.12 and 3.13 of RabbitMQ in Antelope. By default, Antelope -Kolla-Ansible will deploy version 3.11. If you wish to deploy a later version, -you must override the image. if you want to use version 3.12 change -``rabbitmq_image`` in ``globals.yml`` as follows: +Operators can customize or extend these allowed upgrade paths by overriding +this variable in ``globals.yml``. .. code-block:: yaml - rabbitmq_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/rabbitmq-3-12" - -You can then upgrade RabbitMQ with the usual command: + rabbitmq_allowed_upgrades: + "3.13": + - "4.0" + - "4.1" + - "4.2" + "4.0": + - "4.1" + - "4.2" + +If an invalid upgrade path is detected, the deployment will fail with a +descriptive error message during the ``rabbitmq-version-check`` task, +suggesting the next appropriate intermediate version. + +Handling Stream Replicas +~~~~~~~~~~~~~~~~~~~~~~~~ + +RabbitMQ streams are expected to be replicated across the nodes in the +cluster. However, RabbitMQ itself will only create replicas of a stream when +the stream is initially declared. This means that any streams declared when a +RabbitMQ node is out of service must be explicitly managed by an operator. +RabbitMQ documents how to manage stream replicas here: +https://www.rabbitmq.com/docs/streams#member-management + +An example script to create any missing stream replicas can be found under +`kolla-ansible/contrib/ops/rabbitmq/rabbitmq-repair-stream-replicas.sh +<https://opendev.org/openstack/kolla-ansible/src/branch/master/contrib/ops/rabbitmq/rabbitmq-repair-stream-replicas.sh>`__. +This should be executed from a host running the RabbitMQ container. +Currently, membership changes for streams `is not entirely safe +<https://github.com/rabbitmq/rabbitmq-server/discussions/14246>`__, so this +script should only be used when the RabbitMQ cluster is in a known healthy +state. + +Streams Retention Period +~~~~~~~~~~~~~~~~~~~~~~~~ + +When using RabbitMQ streams for fanout queues by setting +``om_enable_rabbitmq_stream_fanout: true``, users can set retention policy for +them with the use of two variables ``rabbitmq_stream_max_segment_size_bytes`` +and ``rabbitmq_stream_segment_max_age`` to avoid running out of disk space +eventually. + +Default configuration set segments of a stream queues to have maximum size of +500 MB (`RabbitMQ default <https://www.rabbitmq.com/docs/streams#declaring>`__) +and the retention time of 1800 seconds once a segment reaches the maximum size +(`oslo.messaging default +<https://docs.openstack.org/oslo.messaging/latest/configuration/opts.html#oslo_messaging_rabbit.rabbit_transient_queues_ttl>`__). +These default values will leave large number of ready messages in stream +queues even though old ones are removed by the retention policy. +So it is recommended to tune them based on how busy the cloud is. + +``rabbitmq_stream_max_segment_size_bytes`` sets the maximum size of stream +segments. This variable needs to be positive integer. + +``rabbitmq_stream_segment_max_age`` sets the retention time of segments that +reached the maximum size. This variable needs to be string with valid options +of Y, M, D, h, m, s (e.g. 24h for 24 hours). -.. code-block:: console - - kolla-ansible upgrade --tags rabbitmq +.. code-block:: yaml -Note again that RabbitMQ does not support upgrades between more than one major -version, so if you wish to upgrade to version 3.13 you must first upgrade to -3.12. + # Example custom retention policy configuration + rabbitmq_stream_max_segment_size_bytes: 5000 # 5 KB + rabbitmq_stream_segment_max_age: "60s" # 60 seconds diff --git a/doc/source/reference/networking/designate-guide.rst b/doc/source/reference/networking/designate-guide.rst index 058af33b5..a46eb4da3 100644 --- a/doc/source/reference/networking/designate-guide.rst +++ b/doc/source/reference/networking/designate-guide.rst @@ -9,12 +9,12 @@ Overview Designate provides DNSaaS services for OpenStack: -- REST API for domain/record management -- Multi-tenant -- Integrated with Keystone for authentication -- Framework in place to integrate with Nova and Neutron +* REST API for domain/record management +* Multi-tenant +* Integrated with Keystone for authentication +* Framework in place to integrate with Nova and Neutron notifications (for auto-generated records) -- Support for Bind9 and Infoblox out of the box +* Support for Bind9 and Infoblox out of the box Configuration on Kolla deployment ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -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:: @@ -51,10 +51,10 @@ Configure Designate options in ``/etc/kolla/globals.yml`` .. important:: If multiple nodes are assigned to be Designate workers, then you must - enable a supported coordination backend, currently only ``redis`` + 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 ``redis`` - when ``redis`` is enabled (``enable_redis`` is set to ``yes``). + ``designate_coordination_backend`` variable. It defaults to ``valkey`` + 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 fab86ce73..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,10 +275,26 @@ 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. +When in need of running `ovn-nbctl` or `ovn-sbctl` commands it's most +convenient to run them from ``ovn_northd`` container: + +.. code-block:: console + + docker exec ovn_northd ovn-nbctl show + +Additional command-line arguments can be passed to the ``ovn-northd`` daemon +using the ``ovn_northd_cmdline_extras`` variable. This can be useful for +tuning performance parameters: + +.. path /etc/kolla/globals.yml +.. code-block:: yaml + + ovn_northd_cmdline_extras: "--n-threads=8 --use-parallel-build --inactivity-probe=10000" + Mellanox Infiniband (ml2/mlnx) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -290,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 @@ -332,6 +348,22 @@ To add custom kernel modules for Neutron, modify the configuration in In this example: -- `neutron_modules_extra`: Allows users to specify additional modules and +* `neutron_modules_extra`: Allows users to specify additional modules and their associated parameters. The given configuration adjusts the `hashsize` parameter for the `nf_conntrack_tftp` module. + +Running Neutron agents subprocesses in separate containers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There is a feature in Kolla-Ansible that allows to overcome +the issue of breaking data plane connectivity, dhcp and metadata services +when restarting neutron-l3-agent and neutron-dhcp-agent in ml2/ovs or +restarting the neutron-ovn-metadata-agent in ml2/ovn. + +To enable it, modify the configuration in ``/etc/kolla/globals.yml``: + +.. code-block:: yaml + + neutron_agents_wrappers: "yes" + +For additional details see `bug 1891469 <https://launchpad.net/bugs/1891469>`_ diff --git a/doc/source/reference/networking/octavia.rst b/doc/source/reference/networking/octavia.rst index 4795207af..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 @@ -147,15 +147,15 @@ disk. you can customize this flavor by changing ``octavia_amp_flavor`` in See the ``os_nova_flavor`` Ansible module for details. Supported parameters are: -- ``disk`` -- ``ephemeral`` (optional) -- ``extra_specs`` (optional) -- ``flavorid`` (optional) -- ``is_public`` (optional) -- ``name`` -- ``ram`` -- ``swap`` (optional) -- ``vcpus`` +* ``disk`` +* ``ephemeral`` (optional) +* ``extra_specs`` (optional) +* ``flavorid`` (optional) +* ``is_public`` (optional) +* ``name`` +* ``ram`` +* ``swap`` (optional) +* ``vcpus`` The following defaults are used: @@ -180,27 +180,27 @@ parameters: The network parameter has the following supported parameters: -- ``external`` (optional) -- ``mtu`` (optional) -- ``name`` -- ``provider_network_type`` (optional) -- ``provider_physical_network`` (optional) -- ``provider_segmentation_id`` (optional) -- ``shared`` (optional) -- ``subnet`` +* ``external`` (optional) +* ``mtu`` (optional) +* ``name`` +* ``provider_network_type`` (optional) +* ``provider_physical_network`` (optional) +* ``provider_segmentation_id`` (optional) +* ``shared`` (optional) +* ``subnet`` The subnet parameter has the following supported parameters: -- ``allocation_pool_start`` (optional) -- ``allocation_pool_end`` (optional) -- ``cidr`` -- ``enable_dhcp`` (optional) -- ``gateway_ip`` (optional) -- ``name`` -- ``no_gateway_ip`` (optional) -- ``ip_version`` (optional) -- ``ipv6_address_mode`` (optional) -- ``ipv6_ra_mode`` (optional) +* ``allocation_pool_start`` (optional) +* ``allocation_pool_end`` (optional) +* ``cidr`` +* ``enable_dhcp`` (optional) +* ``gateway_ip`` (optional) +* ``name`` +* ``no_gateway_ip`` (optional) +* ``ip_version`` (optional) +* ``ipv6_address_mode`` (optional) +* ``ipv6_ra_mode`` (optional) For example: @@ -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 ~~~~~~~~~~~~~~ @@ -340,7 +330,7 @@ Now deploy Octavia: Amphora image ------------- -It is necessary to build an Amphora image. On CentOS / Rocky 9: +It is necessary to build an Amphora image. On CentOS / Rocky 10: .. code-block:: console 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 78fdf4821..95e82031e 100644 --- a/doc/source/reference/orchestration-and-nfv/tacker-guide.rst +++ b/doc/source/reference/orchestration-and-nfv/tacker-guide.rst @@ -30,7 +30,7 @@ Preparation and Deployment ~~~~~~~~~~~~~~~~~~~~~~~~~~ By default tacker and required services are disabled in -the ``group_vars/all.yml`` file. +the ``group_vars/all/tacker.yml`` file. In order to enable them, you need to edit the file ``/etc/kolla/globals.yml`` and set the following variables: @@ -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/rating/cloudkitty-guide.rst b/doc/source/reference/rating/cloudkitty-guide.rst index 061e09675..dbe88b9c7 100644 --- a/doc/source/reference/rating/cloudkitty-guide.rst +++ b/doc/source/reference/rating/cloudkitty-guide.rst @@ -60,7 +60,7 @@ Cloudkitty Storage Backend ~~~~~~~~~~~~~~~~~~~~~~~~~~ As for collectors, CloudKitty supports multiple backend to store ratings. -By default, Kolla Ansible uses the InfluxDB based backend. +By default, Kolla Ansible uses the SQLAlchemy based backend. Another famous alternative is OpenSearch and can be activated in Kolla Ansible using the ``cloudkitty_storage_backend`` configuration option in diff --git a/doc/source/reference/shared-services/glance-guide.rst b/doc/source/reference/shared-services/glance-guide.rst index 03b4c7406..d8e73e44d 100644 --- a/doc/source/reference/shared-services/glance-guide.rst +++ b/doc/source/reference/shared-services/glance-guide.rst @@ -15,7 +15,6 @@ backends: * file * ceph -* vmware File backend ~~~~~~~~~~~~ @@ -49,19 +48,6 @@ To enable the ceph backend manually: glance_backend_ceph: "yes" -VMware backend -~~~~~~~~~~~~~~ - -To make use of VMware datastores as a glance backend, -enable `glance_backend_vmware` and refer to :doc:`../compute/vmware-guide` for -further VMware configuration. - -To enable the vmware backend manually: - -.. code-block:: yaml - - glance_backend_vmware: "yes" - Glance with S3 Backend ~~~~~~~~~~~~~~~~~~~~~~ @@ -113,7 +99,7 @@ need to be enabled. .. code-block:: yaml - glance_enable_rolling_upgrade: "yes" + glance_enable_rolling_upgrade: true .. warning:: @@ -132,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 @@ -145,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:: @@ -168,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 @@ -184,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 d0958a3f9..173766022 100644 --- a/doc/source/reference/shared-services/keystone-guide.rst +++ b/doc/source/reference/shared-services/keystone-guide.rst @@ -96,13 +96,27 @@ 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 +authentication has timeout: + +``keystone_federation_oidc_error_page_retry_login_delay_milliseconds`` + Default is 5000 milliseconds (5 seconds). + +It is also possible to override the ``OIDCHTMLErrorTemplate``, +the custom error template page via: + +.. code-block:: yaml + + {{ node_custom_config }}/keystone/federation/modoidc-error-page.html Identity providers configurations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -117,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 2e900458d..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 @@ -58,8 +58,8 @@ FlashArray drivers in the same OpenStack cluster. Also set the values for the following parameters in ``/etc/kolla/globals.yml``: -- ``pure_api_token`` -- ``pure_san_ip`` +* ``pure_api_token`` +* ``pure_san_ip`` For details on how to use these parameters, refer to the `Pure Storage Cinder Reference Guide <https://docs.openstack.org/cinder/latest/configuration/block-storage/drivers/pure-storage-driver.html>`_. 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 cd674d8cc..9766c053a 100644 --- a/doc/source/reference/storage/cinder-guide.rst +++ b/doc/source/reference/storage/cinder-guide.rst @@ -21,11 +21,11 @@ HA When using cinder-volume in an HA configuration (more than one host in cinder-volume/storage group): -- Make sure that the driver you are using supports `Active/Active High +* Make sure that the driver you are using supports `Active/Active High Availability <https://docs.openstack.org/cinder/|OPENSTACK_RELEASE|/reference/support-matrix.html#operation_active_active_ha>`__ configuration -- Add ``cinder_cluster_name: example_cluster_name`` to your ``globals.yml`` (or +* Add ``cinder_cluster_name: example_cluster_name`` to your ``globals.yml`` (or host_vars for advanced multi-cluster configuration) .. note:: @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -275,12 +254,6 @@ that appears in cinder.conf: * - Network File System (NFS) - cinder_backend_nfs_name - nfs-1 - * - VMware Virtual Machine Disk File - - cinder_backend_vmwarevc_vmdk_name - - vmwarevc-vmdk - * - VMware VStorage (Object Storage) - - cinder_backend_vmware_vstorage_object_name - - vmware-vstorage-object * - Quobyte Storage for OpenStack - cinder_backend_quobyte_name - QuobyteHD diff --git a/doc/source/reference/storage/external-ceph-guide.rst b/doc/source/reference/storage/external-ceph-guide.rst index f37678eb2..a831015ba 100644 --- a/doc/source/reference/storage/external-ceph-guide.rst +++ b/doc/source/reference/storage/external-ceph-guide.rst @@ -312,24 +312,6 @@ for use with availability zones: * ``/etc/kolla/config/nova/<hostname2>/ceph2.conf`` * ``/etc/kolla/config/nova/<hostname2>/ceph2.client.cinder.keyring`` -If ``zun`` is enabled, and you wish to use cinder volumes with zun, -it must also be configured to allow access to Cinder volumes: - -* Enable Cinder Ceph backend for Zun in ``globals.yml``: - - .. code-block:: yaml - - zun_configure_for_cinder_ceph: "yes" - -* Copy Ceph configuration file to: - - * ``/etc/kolla/config/zun/zun-compute/ceph.conf`` - -* Copy Ceph keyring file(s) to: - - * ``/etc/kolla/config/zun/zun-compute/ceph.client.cinder.keyring`` - - Nova ---- @@ -412,7 +394,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``: @@ -583,13 +565,3 @@ HTTPS (443) port will be used. For example: The HAProxy frontend port is defined via ``ceph_rgw_port``, and defaults to 6780. - -Cephadm and Ceph Client Version -=============================== -When configuring Zun with Cinder volumes, kolla-ansible installs some -Ceph client packages on zun-compute hosts. You can set the version -of the Ceph packages installed by, - -* Configuring Ceph version details in ``/etc/kolla/globals.yml``: - - * ``ceph_version`` (default: ``pacific``) diff --git a/doc/source/reference/storage/index.rst b/doc/source/reference/storage/index.rst index d363954a1..42b35f9e3 100644 --- a/doc/source/reference/storage/index.rst +++ b/doc/source/reference/storage/index.rst @@ -15,3 +15,4 @@ supported by kolla. cinder-guide-lightbits manila-guide manila-hnas-guide + manila-pure-guide diff --git a/doc/source/reference/storage/manila-guide.rst b/doc/source/reference/storage/manila-guide.rst index 72ab4b2a7..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*) @@ -323,13 +323,13 @@ Use the manila migration command, as shown in the following example: --new_share_type share_type --new_share_network share_network \ shareID destinationHost -- ``--force-host-copy``: Forces the generic host-based migration mechanism and +* ``--force-host-copy``: Forces the generic host-based migration mechanism and bypasses any driver optimizations. -- ``destinationHost``: Is in this format ``host#pool`` which includes +* ``destinationHost``: Is in this format ``host#pool`` which includes destination host and pool. -- ``--writable`` and ``--preserve-metadata``: Are only for driver assisted. -- ``--new_share_network``: Only if driver supports shared network. -- ``--new_share_type``: Choose share type compatible with destinationHost. +* ``--writable`` and ``--preserve-metadata``: Are only for driver assisted. +* ``--new_share_network``: Only if driver supports shared network. +* ``--new_share_type``: Choose share type compatible with destinationHost. Checking share migration progress --------------------------------- @@ -417,10 +417,10 @@ volumes in the system by adding the following in ``/etc/kolla/globals.yml``: manila_glusterfs_ssh_password: "<glusterfs ssh password>" manila_glusterfs_mount_point_base: "$state_path/mnt" -- ``manila_glusterfs_target``: If it’s of the format +* ``manila_glusterfs_target``: If it’s of the format <username>@<glustervolserver>:/<glustervolid>, then we ssh to <username>@<glustervolserver> to execute gluster (<username> is supposed to have administrative privileges on <glustervolserver>). -- ``manila_glusterfs_ssh_password``: configuration options are only required +* ``manila_glusterfs_ssh_password``: configuration options are only required when the GlusterFS server runs remotely rather than on the system running the Manila share service. diff --git a/doc/source/reference/storage/manila-hnas-guide.rst b/doc/source/reference/storage/manila-hnas-guide.rst index 33124a174..107205982 100644 --- a/doc/source/reference/storage/manila-hnas-guide.rst +++ b/doc/source/reference/storage/manila-hnas-guide.rst @@ -12,11 +12,11 @@ provides NFS Shared File Systems to OpenStack. Requirements ------------ -- Hitachi NAS Platform Models 3080, 3090, 4040, 4060, 4080, and 4100. +* Hitachi NAS Platform Models 3080, 3090, 4040, 4060, 4080, and 4100. -- HNAS/SMU software version is 12.2 or higher. +* HNAS/SMU software version is 12.2 or higher. -- HNAS configuration and management utilities to create a storage pool (span) +* HNAS configuration and management utilities to create a storage pool (span) and an EVS. - GUI (SMU). @@ -30,27 +30,27 @@ The driver supports CIFS and NFS shares. The following operations are supported: -- Create a share. +* Create a share. -- Delete a share. +* Delete a share. -- Allow share access. +* Allow share access. -- Deny share access. +* Deny share access. -- Create a snapshot. +* Create a snapshot. -- Delete a snapshot. +* Delete a snapshot. -- Create a share from a snapshot. +* Create a share from a snapshot. -- Extend a share. +* Extend a share. -- Shrink a share. +* Shrink a share. -- Manage a share. +* Manage a share. -- Unmanage a share. +* Unmanage a share. Preparation and Deployment @@ -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 new file mode 100644 index 000000000..9cb3e756a --- /dev/null +++ b/doc/source/reference/storage/manila-pure-guide.rst @@ -0,0 +1,286 @@ +.. _manila-pure-guide: + +========================================================== +Pure Storage FlashBlade File Services Driver for OpenStack +========================================================== + +Overview +~~~~~~~~ +The Pure Storage FlashBlade File Services Driver for OpenStack +provides NFS Shared File Systems to OpenStack. + + +Requirements +------------ +- Pure Storage FlashBlade + +- Purity//FB v2.3.0 or higher + + +Supported shared file systems and operations +-------------------------------------------- +The driver supports NFS shares. + +The following operations are supported: + +- Create a share. + +- Delete a share. + +- Allow share access. + +- Deny share access. + +- Create a snapshot. + +- Delete a snapshot. + +- Revert from snapshot. + +- Extend a share. + +- Shrink a share. + + +Preparation and Deployment +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. important :: + + It is mandatory that FlashBlade management interface is reachable from the + Shared File System node through the admin network, while the selected + EVS data interface is reachable from OpenStack Cloud, such as through + Neutron flat networking. + + +Configuration on Kolla deployment +--------------------------------- + +Enable Shared File Systems service and FlashBlade driver in +``/etc/kolla/globals.yml`` + +.. code-block:: yaml + + enable_manila: true + enable_manila_backend_flashblade: true + +Configure the OpenStack networking so it can reach FlashBlade Management +interface and FlashBlade Data interface. + +To configure two physical networks, physnet1 and physnet2, with +ports eth1 and eth2 associated respectively: + +In ``/etc/kolla/globals.yml`` set: + +.. code-block:: yaml + + neutron_bridge_name: "br-ex,br-ex2" + neutron_external_interface: "eth1,eth2" + +.. note:: + + ``eth1`` is used to Neutron external interface and ``eth2`` is + used to FlashBlade data interface. + +FlashBlade back end configuration +--------------------------------- + +In ``/etc/kolla/globals.yml`` uncomment and set: + +.. code-block:: yaml + + manila_flashblade_mgmt_vip: "172.24.44.15" + manila_flashblade_data_vip: "172.24.45.22" + manila_flashblade_api: "<API token for admin-privilaged user>" + +Configuration on FlashBlade +--------------------------- + +Create the FlashBlade data network in Kolla OpenStack: + +List the available tenants: + +.. code-block:: console + + $ openstack project list + +Create a network to the given tenant (service), providing the tenant ID, +a name for the network, the name of the physical network over which the +virtual network is implemented, and the type of the physical mechanism by +which the virtual network is implemented: + +.. code-block:: console + + $ openstack network create --project <SERVICE_ID> \ + --provider-physical-network physnet2 \ + --provider-network-type flat \ + flashblade_network + +*Optional* - List available networks: + +.. code-block:: console + + $ openstack network list + +Create a subnet to the same tenant (service), the gateway IP of this subnet, +a name for the subnet, the network ID created before, and the CIDR of +subnet: + +.. code-block:: console + + $ openstack subnet create --project <SERVICE_ID> --gateway <GATEWAY> \ + --subnet_range <SUBNET_CIDR> flashblade_subnet + +*Optional* - List available subnets: + +.. code-block:: console + + $ openstack subnet list + +Add the subnet interface to a router, providing the router ID and subnet +ID created before: + +.. code-block:: console + + $ openstack router add submet <ROUTER_ID> <SUBNET_ID> + +Create a share +~~~~~~~~~~~~~~ + +Create a default share type before running manila-share service: + +.. code-block:: console + + $ openstack share type create default_share_flashblade False + + +--------------------------------------+--------------------------+------------+------------+--------------------------------------+-------------------------+ + | ID | Name | visibility | is_default | required_extra_specs | optional_extra_specs | + +--------------------------------------+--------------------------+------------+------------+--------------------------------------+-------------------------+ + | 3e54c8a2-1e50-455e-89a0-96bb52876c35 | default_share_flashblade | public | - | driver_handles_share_servers : False | snapshot_support : True | + +--------------------------------------+--------------------------+------------+------------+--------------------------------------+-------------------------+ + +Create a NFS share using the FlashBlade back end: + +.. code-block:: console + + $ openstack share create --name <myflashbladeshare \ + --description "My Manila share" \ + --share-type default_share_flashblade \ + NFS 1 + +Verify Operation: + +.. code-block:: console + + $ openstack share list + + +--------------------------------------+-------------------+------+-------------+-----------+-----------+--------------------------+-----------------+-------------------+ + | ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | + +--------------------------------------+-------------------+------+-------------+-----------+-----------+--------------------------+-----------------+-------------------+ + | 721c0a6d-eea6-41af-8c10-72cd98985203 | myflashbladeshare | 1 | NFS | available | False | default_share_flashblade | control@fb1#FB1 | nova | + +--------------------------------------+-------------------+------+-------------+-----------+-----------+--------------------------+-----------------+-------------------+ + +.. code-block:: console + + $ openstack share show myflashbladeshare + + +-----------------------------+-----------------------------------------------------------------+ + | Property | Value | + +-----------------------------+-----------------------------------------------------------------+ + | status | available | + | share_type_name | default_share_flashblade | + | description | My Manila share | + | availability_zone | nova | + | share_network_id | None | + | export_locations | | + | | path = 172.24.53.1:/shares/45ed6670-688b-4cf0-bfe7-34956648fb84 | + | | preferred = False | + | | is_admin_only = False | + | | id = e81e716f-f1bd-47b2-8a56-2c2f9e33a98e | + | | share_instance_id = 45ed6670-688b-4cf0-bfe7-34956648fb84 | + | share_server_id | None | + | host | control@fb1#FB1 | + | access_rules_status | active | + | snapshot_id | None | + | is_public | False | + | task_state | None | + | snapshot_support | True | + | id | 721c0a6d-eea6-41af-8c10-72cd98985203 | + | size | 1 | + | user_id | ba7f6d543713488786b4b8cb093e7873 | + | name | myflashbladeshare | + | share_type | 3e54c8a2-1e50-455e-89a0-96bb52876c35 | + | has_replicas | False | + | replication_type | None | + | created_at | 2016-10-14T14:50:47.000000 | + | share_proto | NFS | + | consistency_group_id | None | + | source_cgsnapshot_member_id | None | + | project_id | c3810d8bcc3346d0bdc8100b09abbbf1 | + | metadata | {} | + +-----------------------------+-----------------------------------------------------------------+ + +.. _flashblade_configure_multiple_back_ends: + +Configure multiple back ends +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +An administrator can configure an instance of Manila to provision shares from +one or more back ends. Each back end leverages an instance of a vendor-specific +implementation of the Manila driver API. + +The name of the back end is declared as a configuration option +share_backend_name within a particular configuration stanza that contains the +related configuration options for that back end. + +So, in the case of an multiple back ends deployment, it is necessary to change +the default share backends before deployment. + +Modify the file ``/etc/kolla/config/manila.conf`` and add the contents: + +.. path /etc/kolla/config/manila.conf +.. code-block:: ini + + [DEFAULT] + enabled_share_backends = generic,fb1,fb2 + +Modify the file ``/etc/kolla/config/manila-share.conf`` and add the contents: + +.. path /etc/kolla/config/manila-share.conf +.. code-block:: ini + + [generic] + share_driver = manila.share.drivers.generic.GenericShareDriver + interface_driver = manila.network.linux.interface.OVSInterfaceDriver + driver_handles_share_servers = True + service_instance_password = manila + service_instance_user = manila + service_image_name = manila-service-image + share_backend_name = GENERIC + + [fb1] + share_backend_name = FB1 + share_driver = manila.share.drivers.purestorage.flashblade.FlashBladeShareDriver + driver_handles_share_servers = False + flashblade_mgmt_vip = <fb1_mgmt_ip> + flashblade_data_vip = <fb1_data_ip> + flashblade_api = <FB1 API token> + + [fb2] + share_backend_name = FB2 + share_driver = manila.share.drivers.purestorage.flashblade.FlashBladeShareDriver + driver_handles_share_servers = False + flashblade_mgmt_vip = <fb2_mgmt_ip> + flashblade_data_vip = <fb2_data_ip> + flashblade_api = <FB2 API token> + +For more information about how to manage shares, see the +:manila-doc:`Manage shares <user/create-and-manage-shares.html>`. + +For details on how to use the Pure Storage FlashBlade, refer to the +`Pure Storage Manila Reference Guide <https://docs.openstack.org/manila/latest/configuration/shared-file-systems/drivers/purestorage-flashblade-driver.html>`_. + +The use of this backend requires that the ``purity_fb`` SDK package is +installed in the ``manila-share`` container. To do this follow the steps +outlined in the `kolla image building guide <https://docs.openstack.org/kolla/latest/admin/image-building.html>`_ +particularly the ``Package Customisation`` and ``Custom Repos`` sections. 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/multinode.rst b/doc/source/user/multinode.rst index 21bf67fa4..5a0db7cf2 100644 --- a/doc/source/user/multinode.rst +++ b/doc/source/user/multinode.rst @@ -136,7 +136,7 @@ host or group variables: <https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#ansible-variable-precedence>`__ are quite complex, but it is worth becoming familiar with them if using host and group variables. The playbook group variables in -``ansible/group_vars/all.yml`` define global defaults, and these take +``ansible/group_vars/all/`` define global defaults, and these take precedence over variables defined in an inventory file and inventory ``group_vars/all``, but not over inventory ``group_vars/*``. Variables in 'extra' files (``globals.yml``) have the highest precedence, so any variables diff --git a/doc/source/user/operating-kolla.rst b/doc/source/user/operating-kolla.rst index b0e97b383..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 @@ -128,8 +127,8 @@ most likely in Other files which may need manual updating are: -- ``/etc/kolla/globals.yml`` -- ``/etc/kolla/passwords.yml`` +* ``/etc/kolla/globals.yml`` +* ``/etc/kolla/passwords.yml`` For ``globals.yml``, it is best to follow the release notes (mentioned above). For ``passwords.yml``, one needs to use ``kolla-mergepwd`` and ``kolla-genpwd`` @@ -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 @@ -198,22 +197,35 @@ After this command is complete, the containers will have been recreated from the new images and all database schema upgrades and similar actions performed for you. -Cleanup the Keystone admin port (Zed only) ------------------------------------------- -The Keystone admin port is no longer used in Zed. The admin interface points -to the common port. However, during upgrade, the port is preserved for -intermediate compatibility. To clean up the port, it is necessary to run -the ``deploy`` action for Keystone. Additionally, the generated -``admin-openrc.sh`` file may need regeneration as it used the admin -port: +CLI Command Completion +~~~~~~~~~~~~~~~~~~~~~~ + +Kolla Ansible supports shell command completion to make the CLI easier to use. + +To enable Bash completion, generate the completion script: + +.. code-block:: console + + kolla-ansible complete --shell bash > ~/.kolla_ansible_completion.sh + +Then, add the following line to your ``~/.bashrc`` file: + +.. code-block:: console + + source ~/.kolla_ansible_completion.sh + +Finally, reload your shell configuration: .. code-block:: console - kolla-ansible deploy --tags keystone - kolla-ansible post-deploy + source ~/.bashrc + +.. note:: + + If you're using a shell other than Bash, replace ``--shell bash`` with your shell type, + e.g., ``zsh``, and adapt your shell's configuration file accordingly. -After these commands are complete, there are no leftovers of the admin port. Tips and Tricks ~~~~~~~~~~~~~~~ @@ -221,16 +233,13 @@ Tips and Tricks Kolla Ansible CLI ----------------- -When running the ``kolla-ansible`` CLI, additional arguments may be passed to -``ansible-playbook`` via the ``EXTRA_OPTS`` environment variable. - ``kolla-ansible deploy -i INVENTORY`` is used to deploy and start all Kolla containers. ``kolla-ansible destroy -i INVENTORY`` is used to clean up containers and volumes in the cluster. -``kolla-ansible mariadb_recovery -i INVENTORY`` is used to recover a +``kolla-ansible mariadb-recovery -i INVENTORY`` is used to recover a completely stopped mariadb cluster. ``kolla-ansible prechecks -i INVENTORY`` is used to check if all requirements @@ -259,6 +268,10 @@ images on hosts. files for enabled OpenStack services, without then restarting the containers so it is not applied right away. +``kolla-ansible validate-config -i INVENTORY`` is used to validate generated +configuration files of enabled OpenStack services. By default, the results are +saved to ``/var/log/kolla/config-validate`` when issues are detected. + ``kolla-ansible ... -i INVENTORY1 -i INVENTORY2`` Multiple inventories can be specified by passing the ``--inventory`` or ``-i`` command line option multiple times. This can be useful to share configuration between multiple environments. @@ -302,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 48d3d1f48..f61e972cc 100644 --- a/doc/source/user/quickstart-development.rst +++ b/doc/source/user/quickstart-development.rst @@ -19,9 +19,9 @@ Host machine requirements The host machine must satisfy the following minimum requirements: -- 2 network interfaces -- 8GB main memory -- 40GB disk space +* 2 network interfaces +* 8GB main memory +* 40GB disk space See the :kolla-ansible-doc:`support matrix <user/support-matrix>` for details of supported host Operating Systems. Kolla Ansible supports the default Python @@ -98,11 +98,11 @@ 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 - pip install ./kolla-ansible + pip install -e ./kolla-ansible #. Create the ``/etc/kolla`` directory. @@ -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 ----------------- @@ -186,7 +185,7 @@ There are a few options that are required to deploy Kolla Ansible: - Rocky (``rocky``) - Ubuntu (``ubuntu``) - For newcomers, we recommend to use Rocky Linux 9 or Ubuntu 22.04. + For newcomers, we recommend to use Rocky Linux 10 or Ubuntu 24.04. .. code-block:: console @@ -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,28 +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 - cd kolla-ansible/tools - ./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 @@ -324,8 +323,7 @@ Using OpenStack .. code-block:: console - cd kolla-ansible/tools - ./kolla-ansible post-deploy + kolla-ansible post-deploy * The file will be generated in /etc/kolla/clouds.yaml, you can use it by copying it to /etc/openstack or ~/.config/openstack or setting diff --git a/doc/source/user/quickstart.rst b/doc/source/user/quickstart.rst index 9ec5d9ab0..f2978b95a 100644 --- a/doc/source/user/quickstart.rst +++ b/doc/source/user/quickstart.rst @@ -19,9 +19,9 @@ Host machine requirements The host machine must satisfy the following minimum requirements: -- 2 network interfaces -- 8GB main memory -- 40GB disk space +* 2 network interfaces +* 8GB main memory +* 40GB disk space See the :kolla-ansible-doc:`support matrix <user/support-matrix>` for details of supported host Operating Systems. Kolla Ansible supports the default Python @@ -177,7 +177,7 @@ There are a few options that are required to deploy Kolla Ansible: - Rocky (``rocky``) - Ubuntu (``ubuntu``) - For newcomers, we recommend to use Rocky Linux 9 or Ubuntu 22.04. + For newcomers, we recommend to use Rocky Linux 10 or Ubuntu 24.04. .. code-block:: console @@ -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>`. @@ -261,7 +261,7 @@ There are a few options that are required to deploy Kolla Ansible: * Virtual environment It is recommended to use a virtual environment to execute tasks on the remote - hosts. This is covered + hosts. This is covered in :kolla-ansible-doc:`Virtual Environments <user/virtual-environments.html>`. Deployment diff --git a/doc/source/user/support-matrix.rst b/doc/source/user/support-matrix.rst index 8df522c44..b2ce35427 100644 --- a/doc/source/user/support-matrix.rst +++ b/doc/source/user/support-matrix.rst @@ -9,14 +9,13 @@ Kolla Ansible supports the following host Operating Systems (OS): .. note:: - CentOS Stream 9 is supported as a host OS while Kolla does not publish CS9 + CentOS Stream 10 is supported as a host OS while Kolla does not publish CS10 based images. Users can build them on their own. We recommend using Rocky - Linux 9 images instead. + Linux 10 images instead. -* CentOS Stream 9 -* Debian Bookworm (12) -* Rocky Linux 9 -* Ubuntu Jammy (22.04) +* CentOS Stream 10 +* Debian Trixie (13) +* Rocky Linux 10 * Ubuntu Noble (24.04) Supported container images diff --git a/doc/source/user/troubleshooting.rst b/doc/source/user/troubleshooting.rst index d00a94ca7..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. @@ -88,13 +90,13 @@ You can find all kolla logs in there. /var/lib/docker/volumes/kolla_logs/_data When ``enable_central_logging`` is enabled, to view the logs in a web browser -using Kibana, go to -``http://<kolla_internal_vip_address>:<kibana_server_port>`` or -``http://<kolla_external_vip_address>:<kibana_server_port>``. Authenticate -using ``<kibana_user>`` and ``<kibana_password>``. +using OpenSearch Dashboards, go to +``http://<kolla_internal_vip_address>:<opensearch_dashboards_port>`` or +``http://<kolla_external_vip_address>:<opensearch_dashboards_port>``. Authenticate +using ``opensearch`` and ``<opensearch_dashboards_password>``. The values ``<kolla_internal_vip_address>``, ``<kolla_external_vip_address>`` -``<kibana_server_port>`` and ``<kibana_user>`` can be found in -``<kolla_install_path>/kolla/ansible/group_vars/all.yml`` or if the default -values are overridden, in ``/etc/kolla/globals.yml``. The value of -``<kibana_password>`` can be found in ``/etc/kolla/passwords.yml``. +``<opensearch_dashboards_port>`` can be found in +``<kolla_install_path>/kolla/ansible/group_vars/all/opensearch.yml``. The value +of ``<opensearch_dashboards_password>`` can be found in +``/etc/kolla/passwords.yml``. |