| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Set a unique processname for trove-api to prevent shared-memory
file collisions when running under uWSGI.
Closes-Bug: #2170958
Change-Id: Iee2c76fd8ba11446688b61a9b109c8bdba0fc820
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
(cherry picked from commit 0931b528df42dbd1b9c32feba09ee30716156f32)
|
|
An issue with skipping "healthy check" checks has been resolved.
In task "Fail if containers are unhealthy" in variable
"unhealthy_containers" not appending services with status
"unhealthy", because path to the status incorrect, and search
in filter "selectattr" not work. Tasks skiping, because in
variable "unhealthy_containers" not items.
Closes-Bug: #2156900
Change-Id: I52f78774536e4487c38a500c2c8941eae4386604
Signed-off-by: Kuchinskiy Alexey <kuchinalser@gmail.com>
(cherry picked from commit d30fad4325b80cc82f485a979c0afeaf7647b07f)
|
|
The release note added in
https://review.opendev.org/c/openstack/kolla-ansible/+/994258
refers to certificates_internal_dir, but proxysql-ca.pem is read from
kolla_certificates_dir in stable/2026.1 and older branches.
Change-Id: Id4b352f102124135216579066c32e9ca575a874c
Signed-off-by: Bartosz Bezak <bartosz@stackhpc.com>
|
|
stable/2026.1
|
|
This reverts commit c62d5e509b74fd39b09c272fb731b73088c3a55b.
Reason for revert: Fixing broken tests
Change-Id: Iea1d9ad71c64642fadb7d02d50f9421cbe64acb7
Signed-off-by: Dawud <dawud@stackhpc.com>
(cherry picked from commit 1839ef9a957432b08c81756780e20d7374e5bb89)
|
|
Set writer_is_also_reader to 2 in the Galera hostgroup
configuration so that the backup writer node also serves
reads, instead of sitting idle while all read traffic went
to the single remaining reader node. The writer node is
never added to the reader hostgroup regardless of this
setting, only the backup writer is affected. See bug report
for performance difference details.
Closes-Bug: #2167037
Change-Id: Ib5145c200c3cd70f861824abd967748faf61e1cf
Signed-off-by: fprzewozn <przewozny.franciszek@gmail.com>
(cherry picked from commit 42eec877ff572fd724af8a1c0fa64acf5e824c7b)
|
|
Ansible's "is string" Jinja test returns False for values encrypted
with ansible-vault (AnsibleVaultEncryptedUnicode), so a precheck
using such an encrypted password/salt failed incorrectly. Accept the
value if it is either a plain string or vault_encrypted.
Closes-Bug: #2115495
Change-Id: I0bf783c40ca5be66717193be9dece971805fca55
Signed-off-by: fprzewozn <przewozny.franciszek@gmail.com>
(cherry picked from commit ed74de7e9a76fac01554fc876c4a581b857903ea)
|
|
stable/2026.1
|
|
service-cert-copy falls back to kolla_tls_backend_cert/key when no
rabbitmq-specific cert is found, but the precheck did not check for
this path, causing a false failure when relying on the shared
backend certificate.
Closes-Bug: #2166283
Change-Id: I75d4b33fc893bcf0793c1280981574bcdf3f3002
Signed-off-by: fprzewozn <przewozny.franciszek@gmail.com>
(cherry picked from commit a54ad717f08a8258424004e6224a36ea561393d2)
|
|
check_image() from kolla_docker_worker returns None when the image
doesn't exist locally. This means that when compare_labels tries to read
a value from it, it will error out. This chain happens when comparing an
image that doesn't exist locally. In the past we didn't hit this because
checks ran sequentially and it would exit before hitting this. A recent
change [1] means that now all checks run always.
This patch fixes the issue in two ways. First, it makes the docker
worker return an empty dict from check_image when it doesn't exist.
Second, compare_labels now truthy-checks the output before proceeding,
and returns straight away if it's False.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/978162
Change-Id: I3c33ac3a474f80bca100005f61c1c0bfedc46170
Signed-off-by: Alex Welsh <alex@stackhpc.com>
Closes-Bug: #2166024
(cherry picked from commit ffc50e8d33ade7a0d58ef83b79ed296a28b49608)
|
|
Since Grafana 13.2, the api/user/helpflags/1 endpoint has been removed
[1]. This means the "Disable Getting Started panel" deployment task
fails with 404 when a custom home dashboard is added.
The best alternative I can find is to set default_home_dashboard_path in
grafana.ini, which disables the panel anyway [2]
[1] https://github.com/grafana/grafana/pull/124916
[2] https://github.com/grafana/grafana/pull/28750
Change-Id: I78b8657b6ca94d81e3becbba9d5a476d9427658f
Signed-off-by: Alex Welsh <alex@stackhpc.com>
Closes-Bug: #2166048
(cherry picked from commit c8e7b85b2707f762b2560ad8bed9d107a30ff521)
|
|
Cinder requires service-to-service authentication with Glance to
fetch direct image locations (e.g., for RBD CoW cloning). Because
keystoneauth parameters were not explicitly registered for the
[glance] section, they could not be properly configured and loaded.
This lack of authentication led to HTTP 403 Forbidden errors
during fetch_image_location, forcing a fallback to slow image
downloads.
This patch registers the required keystoneauth options in the
[glance] group, enabling proper service-to-service communication.
Closes-Bug: #2161971
Change-Id: I2cae59b34b1fbd4fa3bf1c5b2da5277ef4712916
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
(cherry picked from commit 1056bc652b148bddc5d4cb667c8d3ef26a322aa9)
|
|
Mariabackup copies the data directory of mariadb_backup_host but
connected through the load balancer, so backup_replica.sh could
redirect it to another Galera member. The backup lock then applied to
the wrong node, leaving the copied files unquiesced.
Connect to api_interface_address and mariadb_port instead, and always
use the local backup script. MariaDB 10.11.19 and 11.4.13 no longer
tolerate the mismatch.
mariadb_backup_target now has no effect, and full backups are named
mysqlbackup-<date>.qp.xbc.xbs.gz, as the restore docs describe.
Closes-Bug: #2165011
Related-Bug: #2125124
Change-Id: I33ebd36c728ff50df8ebf13fc5af9882a0e71d23
Signed-off-by: Bartosz Bezak <bartosz@stackhpc.com>
(cherry picked from commit f1f2702bbe812e285f0766a5787159ba92fdce8b)
|
|
Nova changed in 2026.1 how long their services take to gracefully
shutdown.
The default value of [DEFAULT]/graceful_shutdown_timeout has been
changed from 60 to 180 seconds for all Nova services. [...]
Operators using external system (e.g. k8s, systemd) to manage the
Nova services should ensure that their service stop timeouts are
set to at least graceful_shutdown_timeout to avoid forcefully
killing service before Nova finish its graceful shutdown.
Kolla-Ansible failed to update the period of time that ansible waits
for Nova services to shut down. This causes both CI failures and
failures for deployers when trying to manage some Nova containers.
Prompt: Michael asked for assistance debugging why CI jobs were
failing with nova-scheduler timeouts.
Assisted-By: Claude Opus 5 (1M context, high effort) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context, high effort) <noreply@anthropic.com>
Closes-Bug: #2162860
Change-Id: If7c5a6d885b19e39cfc305440424f10de3a5ea05
Signed-off-by: Michael Still <mikal@stillhq.com>
(cherry picked from commit 4ce86ef1db631c15e6e5e142d2908f73348377d4)
|
|
The key used to group hosts was previously changed[0] but the group not
updated in the task used to distribute fernet keys. When migrating
hosts this could lead to the task being delegated to a host without
keys, resulting in all hosts losing their keys.
0: Change I1db88e28a828ebf073f018b2bae1d9556ec22807
Closes-Bug: #2163158
Change-Id: Ia76f3e6cb41a30b88ac885832755ebe5264ad9fc
Signed-off-by: Owen Jones <owen@stackhpc.com>
(cherry picked from commit 541a26c7d4dd1988eda64327c6b08aa831ee3162)
|
|
When enabling cpuset_cpus or cpuset_mems on existing Docker containers,
Docker may report the current value as an empty string when no cpuset
constraint is configured.
These dimensions are cpuset-list strings, not numeric resource values.
Compare them as strings in the Docker worker instead of passing them
through the numeric dimension comparison logic.
Closes-Bug: 2143874
Change-Id: I1b8cd72846b28f556c8f9a0ba114a8af9221e85a
Signed-off-by: Loan Harrouin <loan.harrouin@gmail.com>
(cherry picked from commit 8304bb3884237bf5aee1c60715d097e88561d56d)
|
|
Change-Id: I8825f41a1753eb323e0fdf1bf38a679670e01ba7
Signed-off-by: Alex Welsh <alex@stackhpc.com>
(cherry picked from commit 37194fcab7883b8626f2eab5a4f6a19246b85ec9)
|
|
|
|
This reverts commit 79f6f2a049bad1d3cb51ba50981a01f63503a329.
Reason for revert: post-config job leaks OpenSearch secret to logs (see failed prometheus-opensearch jobs)
Change-Id: I63432e19c42ac9f3eebebadb474882ccda3780ed
Signed-off-by: fprzewozn <przewozny.franciszek@gmail.com>
|
|
The iscsi role derives the cinder-volume/backup inventory groups from
cinder_enabled_backends, but that variable (along with cinder_backends,
cinder_ceph_backends and the cinder_backend_*_name variables) was only
defined in the cinder role defaults. The iscsi play runs before the
cinder play, so the variable is out of scope there and prechecks (and
deploy/reconfigure) fail with:
'cinder_enabled_backends' is undefined
when a Cinder iSCSI/LVM backend is enabled.
Move these backend variable definitions to group_vars/all/cinder.yml so
they are in scope for every play, including the iscsi role. This also
keeps all cinder backend definitions - including the cinder-backup ceph
backend (cinder_backup_backend_ceph_name, cinder_backup_ceph_backend) -
in one place. All of their dependencies (the enable_cinder_backend_*
flags, cinder_backend_ceph and the ceph_* variables) are already global,
and globals.yml is applied as extra-vars, so operator overrides continue
to take precedence.
Partial-Bug: #2158120
Change-Id: I765f45814382377332ba9f01f1bc52bd4e046170
Signed-off-by: Kari Häkkinen <Kari.Hakkinen@admicom.com>
(cherry picked from commit 2df2ee6e49d0fd58b1781c0b490b019e1936e96b)
|
|
The OIDCXForwardedHeaders directive from mod_auth_openidc accepts a
space-separated list of header names and parses each one as a separate
argument. The keystone httpd template wrapped the value in double
quotes, so Apache passed the whole list as a single argument. As a
result, only a single forwarded header could be configured and setting
more than one value failed.
Remove the surrounding quotes so that each header name is parsed as an
individual argument, allowing more than one forwarded header to be set.
Closes-Bug: #2155147
Change-Id: Id23fbdf6c82acdec1ee310b6b29fc4a5dc846f66
Signed-off-by: Michel Raabe <raabe@b1-systems.de>
(cherry picked from commit 6a710101850a13518d66bd0e7c27a3ee54a3c2d8)
|
|
|
|
There's actually two fixes here
The first waits until the OpenSearch state is healthy before moving on
to Dashboards. Otherwise, OpenSearch Dashboards does its internal
`.kibana` index migration before OpenSearch has fully recovered. This
creates a corrupted `.kibana_1` index, making Dashboard enter an
infinite polling loop and fail to start.
The second adds retries to the "Create OpenSearch Dashboards Index
Pattern" task. Dashboards seems to take a while to start up
post-upgrade, I think again, it's doing some internal migrations for the
latest version. Without first checking the API is ready, it consistently
fails to be ready, and throws 503s by the time we try to create index
patterns.
Change-Id: Ic06ccc6b7ec22fa1b0cfa2a144878672d314e93e
Closes-Bug: #2161333
Signed-off-by: Alex Welsh <alex@stackhpc.com>
(cherry picked from commit 79f6f2a049bad1d3cb51ba50981a01f63503a329)
|
|
Currently, the variable ``valkey_sentinel_tag`` uses the value of
``openstack_tag`` when it needs to inherit the value of ``valkey_tag``.
Furthermore, ``valkey_sentinel_image_full`` does not use the tag value
from ``valkey_sentinel_tag``.
These two problems make valkey container deployment act different to
what's expected from deploying other service containers, which leads to
confusion.
Closes-Bug: #2161716
Change-Id: Iec0b128736f4dde5bb3265b350555f824aba004c
Signed-off-by: Seunghun Lee <seunghun@stackhpc.com>
(cherry picked from commit 7f038b5b2c12b01e713b2d294112d711d5487286)
|
|
stable/2026.1
|
|
|
|
rabbit_qos_prefetch_count was previously set to 1, the lowest
value permitted by oslo.messaging when rabbit_stream_fanout is
enabled (oslo.messaging requires prefetch_count > 0 for stream
queues, since the stream protocol needs a positive credit window
to make progress).
However, non-zero is not the same as optimal. RabbitMQ's own
quorum queue documentation recommends the opposite of what a
prefetch of 1 provides:
"Quorum queues also benefit from consumers using higher
prefetch values to ensure consumers aren't starved whilst
acknowledgements are flowing through the system and allowing
messages to be delivered in a timely fashion."
-- https://www.rabbitmq.com/docs/quorum-queues
With rabbit_quorum_queue enabled by default alongside
rabbit_stream_fanout, prefetch=1 forces every quorum-queue
consumer (nova-conductor, neutron-server, cinder-volume, etc.)
into fully serialized delivery: RabbitMQ will not deliver the
next message to a channel until the previous one has been acked.
Combined with a small worker count, this can turn a burst of RPC
traffic into a queueing delay long enough to exceed
rpc_response_timeout, surfacing as a false-positive
MessagingTimeout with no actual broker outage.
Bump the default to 50. This keeps the value legal for stream
queues (still > 0), keeps a bound on how much a single consumer
can hold in flight, but gives quorum-queue consumers enough
headroom to avoid unnecessary serialization and consumer
starvation under load.
This is a shared value across all services using
oslo_messaging_rabbit, so it is intentionally conservative
rather than tuned per-service; operators with specific
throughput requirements can still override
om_rabbitmq_qos_prefetch_count.
See [1].
[1]: I541f704bfa2e98068096331afbdb591659cbc40b
Change-Id: Iea474a553cb8bd3920ef89c148f63b1c7b1b8dbc
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
(cherry picked from commit 1ccf97e6234dea12811f0a1270055015bd403079)
|
|
stable/2026.1
|
|
ProxySQL frontend TLS (database internal TLS) and backend TLS (database
backend TLS) expects different CA if users use chain of certificates
(e.g. use of intermediate certificates).
Frontend TLS expects the intermediate certificate that signed the leaf
certificate as a CA file, whereas backend TLS expects root CA.
To fix, users are now required to create a file named
``proxysql-ca.pem`` at ``kolla_certificates_dir``, which is a copy of
the intermediate certificate.
If your system is not affected by this bug, you're not required to
create the new file ``proxysql-ca.pem``.
Closes-bug: #2150449
Change-Id: I88911badb0d0801f79317df6681c571cc1c8cfee
Signed-off-by: Seunghun Lee <seunghun@stackhpc.com>
|
|
This change ensures REQUESTS_CA_BUNDLE and SSL_CERT_FILE environment
variables are exported in uWSGI conf, fixing SSL validation errors in
Glance. By default it doesn't inherit from the host, so these must be
included explicitly, otherwise internal communication between glance api
instances will always fail when internal TLS is enabled.
Change-Id: Ifbe3547ba6b933bb1e4d5599be94ba428c4f49c5
Closes-Bug: #2160218
Signed-off-by: Alex Welsh <alex@stackhpc.com>
(cherry picked from commit 9c41bdca79d4c7267beeece141909e679f70dea8)
|
|
We need to restore the /var/lib/nova/compute_id file to avoid
nova-compute failing to start with the following error:
nova.exception.InvalidConfiguration: No local node identity found,
but this is not our first startup on this host. Refusing to start
after potentially having lost that state!
K-A now query IDs of hypervisors by their hostname and create necessary
compute_id file under node config directory for nova-compute before
starting nova-compute containers.
The compute_id file gets copied under /var/lib/nova/ on container start
up.
Co-Authored-By: bjorn lofdahl <bjorn.lofdahl@gmail.com>
Co-Authored-By: Seunghun Lee <seunghun@stackhpc.com>
Co-Authored-By: Owen Jones <owen@stackhpc.com>
Change-Id: If635577fa240f0953ad02d2c28473480d9ad011d
Closes-Bug: #2051011
Signed-off-by: Owen Jones <owen@stackhpc.com>
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
(cherry picked from commit 3e4cfd49da38c7db2ac3ad47a75dc89b14cbb513)
|
|
Split the Grafana blackbox endpoint into separate public and internal
checks. The public endpoint is now only monitored when both Grafana and
``enable_grafana_external`` are enabled (which is the default when
enabling Grafana), matching the HAProxy external listener check.
The internal endpoint remains monitored when Grafana is enabled and
either external Grafana is disabled or the internal and external VIPs
are separate. This avoids losing Grafana monitoring when
``enable_grafana_external`` is disabled.
Closes-Bug: #2157003
Change-Id: Iea3b21dcfa4284f2a74c1bee95577ce8a219cf5f
Signed-off-by: Dawud <dawud@stackhpc.com>
(cherry picked from commit 6e9bea3291a55829b32d58613b0414af547ec4a1)
|
|
This change sets the default Glance uWSGI `chunked-input-limit` to
67108864 (64MB).
Before this change, Glance would use the uWSGI default 1MB. Snapshotting
an instance would hang indefinitely because Nova sends larger chunks.
Change-Id: I43f9232efade5e98bcd67b9c94e7161c790995ce
Closes-Bug: #2158974
Signed-off-by: Alex Welsh <alex@stackhpc.com>
(cherry picked from commit a64dd7075780d6b614aabff7769f4f83a315b680)
|
|
The libvirt daemon ships with max_workers=20 and max_client_requests=5.
Those defaults suit a multi-tenant host serving many mutually
distrustful clients, where the per-client request cap protects the
daemon from any single client monopolising it. Under Kolla-Ansible,
nova-compute is effectively the sole privileged client of libvirtd, so
the cap of 5 concurrent requests per client becomes the binding
constraint rather than a safety net.
When several instances build at once -- as they do during the tempest
run of the upgrade jobs -- nova-compute's concurrent libvirt RPCs
(instance defineXML calls plus the resource-tracker periodic) exceed
five. Further requests queue, the connection's keepalive responses are
starved, and after keepalive_interval (5s) x keepalive_count (5) = 25s
libvirtd closes the connection. nova then sees "Cannot recv data:
Input/output error" mid-defineXML, the build is rescheduled, and once
all hosts are exhausted the instance is left in ERROR. This presents as
flaky upgrade-job failures.
Example failure, on the voting kolla-ansible-debian-bookworm-upgrade
job (stable/2025.2):
https://zuul.opendev.org/t/openstack/build/73ff5a97567d4e05b1774170e0f4aada
with primary/logs/kolla/libvirt/libvirtd.txt showing libvirt's own
recommendation to tune this parameter:
warning : Client hit max requests limit 5. This may result in
keep-alive timeouts. Consider tuning the max_client_requests server
parameter
...
error : connection closed due to keepalive timeout
Raise the per-client cap to 20 -- comfortably above the handful of
concurrent builds plus periodics seen in practice -- and the worker
pool to 50 so that lifting the per-client limit does not starve other
connections such as live migration, health checks and periodic tasks.
Both values are exposed as variables (libvirt_max_client_requests and
libvirt_max_workers) so operators can tune them further.
This is not a Kolla-specific workaround -- the stock libvirtd.conf
comment warns that setting max_client_requests too low "may cause
keepalive timeouts", and since 2022 libvirtd emits the runtime warning
quoted above. As Daniel Berrange explained when he added that warning,
the keepalive packets "are subject to the 'max_client_requests' limit
just like any API calls", so a client that saturates the limit can have
its connection dropped:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5NIJPA7SJVY55VSK7RTEDEHKWOZYJKT6/
Red Hat documents the same tuning for libvirt hosts under load in its
knowledge base, notably "Too many active clients are dropping the
connection" at https://access.redhat.com/solutions/28146.
Assisted-By: Claude Opus 4.8 (1M context, medium effort)
Partial-Bug: 2158515
Change-Id: I131c3d4d57dc73ca4dd421cc8f28465248c9830e
(cherry picked from commit 5acd2f91d22213ef04bd6988a2a0261982b0cf05)
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
Due to implementation choices in qemu and libvirt, standard log
rotate does not work on these console files, and instead the usual
approach is to have libvirt's virtlogd rotate the contents of the
console log file when it gets a bit big. OpenStack Compute knows
how to read data from more than one rotated console log file if
required to service a REST API request.
OpenStack Kolla and Kolla-Ansible deploy OpenStack components in
docker or podman containers. An error in the startup configuration
for the nova_libvirt container results in the libvirt virtlogd
daemon not being run, which results in this console log rotation
not occurring.
This opens up the risk of a disk usage denial of service attack
on a hypervisor. The console log is stored on the same filesystem
as ephemeral disks, and OpenStack Nova will take a hypervisor out
of service if disk space becomes constrained. There is some
protection from the instance console not being able to write data
particularly quickly, but it is definitely still possible to fill
the hypervisor file system -- especially if multiple instances are used.
This misconfiguration appears to exist in all versions of
Kolla / Kolla-Ansible as best as I can tell.
Flip qemu.conf's stdio_handler from "file" to "logd" so libvirt
routes instance console chardevs through virtlogd, which rotates
them per /etc/libvirt/virtlogd.conf. Without this, virtlogd runs
but is never consulted and console.log grows unbounded.
The nova_libvirt command now points at the
/usr/local/bin/kolla_nova_libvirt_start helper shipped in the
image. Deploying this Kolla-Ansible change against an older image
that predates that helper would leave the container unable to
start. Add a deploy-time check that inspects the nova_libvirt
image for the helper and fails with an explanatory message when it
is absent, so an incomplete upgrade (new code, stale image) is
caught before the container is reconfigured.
Partial-Bug: 2155214
Depends-On: https://review.opendev.org/c/openstack/kolla/+/993065
Change-Id: Ia543939b17cd06714695dff8ef8bd29bc3f8175e
(cherry picked from commit 4244e6a91767a4706e59145f6841adbeeac048bb)
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
Remove a stray trailing quote from the barbican_api healthcheck URL.
The quote causes shell parsing failures, incorrectly marking the
container as unhealthy.
Closes-Bug: #2157639
Change-Id: I3e9b791d0ee2ce54af862f3e30e37e6600a350bd
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
(cherry picked from commit e101828d1887522efcd1cf7fae3606efc05f513a)
|
|
Set the Ironic tempdir to be within the Ironic Docker container
volume.
Closes-Bug: #2156758
Change-Id: Ib24a04657f297ebb323686aa1d80f9bf019f44f2
Signed-off-by: Jed Preist <jed@stackhpc.com>
(cherry picked from commit ba5d4219749099cb7a797deb77685c5293fb9bf5)
|
|
Change-Id: I0c8c139b35205996f0322abce9cd399ab97b4924
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
Closes-Bug: #2112280
Change-Id: I52499bdf2b7fc70f91a4c2920749bfef83a79850
Signed-off-by: Rafal Lewandowski <rafal@stackhpc.com>
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
(cherry picked from commit e302bab31f30296f7d6f41c3d46e19cf5668b97a)
|
|
|
|
|
|
|
|
kolla-ansible rabbitmq-reset-state fails because
rabbitmqctl force_reset is not supported with Khepri.
Use rabbitmqctl reset instead.
Closes-Bug: #2150536
Change-Id: Idc275dc830838519e40a519111ae0e5ca2b76edf
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
|
|
|
|
RabbitMQ HAProxy config was missing user/auth in health checks,
causing backend to be marked DOWN and HTTP 500 errors.
Closes-Bug: #2150569
Change-Id: I1949210687bbe8f896e6b973950ddbea03c1f804
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
|
|
Previously, operators had to manually create the default index
pattern after the first login to OpenSearch Dashboards.
This commit automates the creation of the default index pattern
using the OpenSearch Dashboards Saved Objects API during the
post-config phase. The pattern is dynamically named based on the
opensearch_log_index_prefix variable (defaulting to "flog-*")
and automatically sets "@timestamp" as the time field.
Documentation has been updated to reflect that the first-login
manual setup is no longer required for the default log indices.
Change-Id: I8d49a270ace187b3b13103452e93d305505f6cbb
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
|
|
|
|
|
|
|
|
Zun is broken in 2026.1, it has been released broken and there are
no reviews on the patch to fix it [1].
[1]: https://review.opendev.org/c/openstack/zun/+/982362
Depends-On: https://review.opendev.org/c/openstack/ansible-collection-kolla/+/986150
Change-Id: I8ced621754d03c44b7672dd94fc3d7d2173ac734
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
