| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
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)
|
|
stable/2026.1
|
|
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)
|
|
During mariadb_recovery, recover_cluster.yml starts the bootstrap
node, starts the slave containers, and then recreates the master
container to clear pc.bootstrap. The "Wait for slave MariaDB" task
between those steps only waits for the service port to open, but a
freshly started slave is still receiving its state transfer (SST
then IST) at that point. The master restart is a Galera cluster
membership change, and a membership change while a joiner is
mid-IST makes the joiner abort with "IST didn't contain all write
sets, expected last: N last received: N-1 ... node restart
required". The joiner then drops to non-primary, self-leaves, and
sits permanently wsrep-disconnected; nothing restarts it, and the
Galera readiness check added by commit aed9d890 fails the recovery.
Over the last 30 days this hit 16 of 954 mariadb scenario CI runs
(1.7%), was terminal in every case, and accounts for about 30% of
all failures in those jobs, across Debian, Ubuntu and Rocky. The
Ubuntu failures are on MariaDB 11.4.12, which already contains the
upstream fixes for MDEV-36621 and MDEV-39643, so this window has to
be closed at the orchestration layer.
Add a wait for every slave to report wsrep_local_state_comment
Synced before the master restart, using the same defensive until
pattern as the bootstrap WSREP sync wait. The retry budget is
larger than the port waits because a slave may legitimately still
be receiving an SST at this point.
Prompt: Michael asked for a kerbside-patches patch fixing the
mariadb_recovery IST race we diagnosed from the kolla-ansible
989612 gate failures, where the master restart during recovery
races slaves that are still receiving state transfer.
Assisted-By: Claude Fable 5 (200K context, medium effort) <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 (200K context, medium effort) <noreply@anthropic.com>
Closes-Bug: #2161773
Change-Id: Ifd0260fa4875051b1c38ee52de4f0de1806f6cc9
Signed-off-by: Michael Still <mikal@stillhq.com>
(cherry picked from commit cb259a3914180234cef888ddfe34b54f60f240a0)
|
|
The "Wait for first MariaDB service to sync WSREP" handler runs
immediately after MariaDB opens its service port, and queries
wsrep_local_state_comment via the kolla_toolbox mysql_query
module. The first attempt frequently races MariaDB's privilege
bootstrap, so mysql_query can return a failure-shaped dict that
has no query_result key. The existing until expression then dies
with a Jinja AttributeError on result.query_result[0][0]['Value'],
and Ansible treats a template error in until as a hard failure
instead of "still false, retry". The configured retries: 10 /
delay: 6 budget is therefore never spent.
Guard the until expression so it only inspects query_result when
it is defined. mysql_query failures then leave the conditional
cleanly false, and the existing retries: 10 / delay: 6 budget
actually gets used. The first successful query lands within one
or two retries on every matrix we have seen.
Prompt: Michael asked for a patch that makes the MariaDB WSREP
sync wait defensive so that the existing retry budget actually
applies when the first mysql_query call comes back without a
query_result key.
Assisted-By: Claude Opus 4.7 (1M context, medium effort) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context, medium effort) <noreply@anthropic.com>
Change-Id: I4e5d7c2a8f9b1d3e6a4c5b8d2f1e0a3c4b5d6e7f
Signed-off-by: Michael Still <mikal@stillhq.com>
(cherry picked from commit c7792108f78eba3aae3f6278e3e21220b78aa5f9)
|
|
|
|
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>
|
|
Add kolla_toolbox and proxysql-config,
remove common, proxysql and haproxy.
Change-Id: Ia65420a6124f6dc95e3b0c4760ed6a613972e1d0
Signed-off-by: Bartosz Bezak <bartosz@stackhpc.com>
(cherry picked from commit 81eaf351ef7bfde38bb311076a2607e371d785d1)
Signed-off-by: Bartosz Bezak <bartosz@stackhpc.com>
|
|
|
|
Started failing on Rocky 10 with:
Jul 18 09:28:34 localhost iptables.init[857]: Warning: Extension state is not supported, missing kernel module?
Change-Id: Ib7df1eaa8a3f75fe8040fd2d646cf7d02e0322cc
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
(cherry picked from commit 7dc2b7f819e30c046eeb5104a9fbe81a24c97402)
|
|
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)
|
|
From the experience we have made so far, a lot of AI based contributions
tend to cause more work rather than they bring benefit. So we caution
people to avoid this when possible.
The wording of the policy was adapted from the Zuul project [0].
[0] https://review.opendev.org/c/zuul/zuul/+/993998
Co-Authored-By: James E. Blair <jim@acmegating.com>
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I5fcd5bea33c4f4c87b6f6cf0a96514e8d2da3af3
(cherry picked from commit c202c27ba62bd599a1f9d6fcb07cce5234e33361)
|
|
|
|
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)
|
|
Closes-Bug: 2160035
Change-Id: I2f3ef4ef1085c93fd7e697c03fd530885795bcc4
Signed-off-by: alma.maillet-contoz <alma.maillet-contoz@infomaniak.com>
(cherry picked from commit 4784eee7086043610c49c3f06d5e77eb816c9a2e)
|
|
Change-Id: I109f80d8903cb6f9c608ab39d181a001d426fd87
Signed-off-by: Pierre Riteau <pierre@stackhpc.com>
(cherry picked from commit b2e63e2791e49cdca206241e07f27a53f4ac7556)
|
|
The shared periodic-stable-jobs template in openstack-zuul-jobs runs
openstack-tox-py310 on stable/2026.1, but kolla-ansible on this branch
sets python_requires >= 3.11 and requires ansible-core >= 2.19, whose
every satisfying release needs Python >= 3.11. The py310 tox
environment therefore cannot even install: pip fails to resolve
ansible-core in seconds, and the job has failed on every run. In the
30 days to 2026-07-01 that was 30 failures from 30 runs in the
periodic-stable pipeline, pure noise for anyone watching the periodic
dashboards.
Zuul templates cannot exclude individual jobs, so replace the shared
template with an explicit periodic-stable job list running what the
shared template would have run minus the impossible interpreter: docs
and py313. This mirrors the approach already taken for check and gate
on this branch with the local openstack-python3-jobs-kolla-ansible
template, which exists precisely to skip py310 jobs.
Assisted-By: Claude Fable 5 (1M context, medium effort)
Change-Id: I284ab75a3e476e6e623507084cfed5675f77d430
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
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)
|
|
During container config comparison, podman's Docker-compat exec API
inconsistently demultiplexes the 8-byte frame headers from the output
stream depending on podman version, leaving binary bytes in raw_output.
This will raise an "UnicodeDecodeError: 'utf-8' codec can't decode byte
0x?? in position 167: invalid start byte"
Closes-Bug: 2153943
Change-Id: Ida1c017f50b9a24b88f8962d304eb015fa357211
Signed-off-by: Ettore Simone <ettore.simone@gmail.com>
(cherry picked from commit c99f521356012d5bc42ab3c41a994b67657e86f0)
|
|
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)
|
|
There is a possibility that the ansible-runner in kolla_toolbox
is executed with the wrong environment variables if run in a specific
way. The cause is not super clear, but the solution is to simply force
it to use the correct HOME value.
Closes-Bug: #2153544
Change-Id: Ibad84e358f21564c570161f7e4f21b117398df3b
Signed-off-by: Bertrand Lanson <bertrand.lanson@infomaniak.com>
(cherry picked from commit 2104f74a2616821c2bd848411ebfce266a3edd69)
|
|
Keeping this value to true with external RGW as object storage endpoints
can cause outages that are annoying to recover from. We should warn
operators about this.
Change-Id: I37965382bed6b9762782ec3f9ec3103143d738cc
Signed-off-by: Bertrand Lanson <bertrand.lanson@infomaniak.com>
(cherry picked from commit 8510b763fec5fbfdcd677177809c682eb69e97dc)
|
|
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)
|
|
The OVN SB relay port was generated using string concatenation
between the port prefix and relay group ID. When the relay count
exceeded 9, this resulted in invalid port numbers such as 166410.
Update the port calculation to use numeric addition instead,
ensuring ports remain within the expected and valid range.
Closes-Bug: #2131191
Change-Id: I4738339431483c3d38fb322c18888fe61cae1a62
Signed-off-by: amir58118 <sahahmadi96@gmail.com>
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
(cherry picked from commit 6c2b9225d52cf2470d7ed85fa5fde833d764bb3c)
|
|
The check_alive_proxysql.sh script piped raw ASCII text
("show info\n") directly into the admin socket via socat, bypassing
the MySQL handshake.
ProxySQL's MySQL_Data_Stream interprets the first 3 bytes of "show"
as a little-endian packet length (7301235), which has always been
semantically wrong - the check only appeared to work because socat
received ProxySQL's binary handshake greeting back and exited 0.
ProxySQL 3.0.9 introduced a pre-authentication bounds check
(GHSA-58ww-865x-grpr) that explicitly rejects first packets whose
declared length exceeds the 32 KB input queue capacity and closes
the connection.
This causes socat to exit non-zero, making keepalived mark ProxySQL
as unhealthy on every check interval.
Replace the raw socat probe with a mariadb client connection that
speaks proper MySQL protocol against the admin socket.
Closes-Bug: #2155865
Depends-On: https://review.opendev.org/c/openstack/kolla/+/992394
Change-Id: Ic090916509cbb1bd98c96e8beb32ec9e90bfc6aa
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
(cherry picked from commit 1e0fa6c62bbb6129f29f01605a00ce3e0f50e27a)
|
|
|
|
This makes things more consistent. I'm hoping to rely on this in kayobe
to make the --kolla-playbook work when we make multiple calls to
kolla-ansible in the same command invocation.
Change-Id: Ieac1f4c7cf1cba19d08ac872bba60794af029110
Signed-off-by: Will Szumski <will@stackhpc.com>
(cherry picked from commit f699a60283e5b1b4ac247b0759c862d59e1c3150)
|
|
Change-Id: Ib82e708137679ae85f645c448cc8aa3cf583cf6d
Signed-off-by: Bartosz Bezak <bartosz@stackhpc.com>
(cherry picked from commit 6b2112f0bc8f99d31fb7f447728af8f55db3596d)
|
|
Change-Id: I0c8c139b35205996f0322abce9cd399ab97b4924
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
Skyline nginx service locations are defined without a trailing
slash while proxy_pass includes a trailing slash. This can produce
paths with a double leading slash, for example
//resource_providers for Placement. Some WSGI deployments
may treat such paths literally and return errors instead
of normalizing them.
Closes-Bug: #2151770
Change-Id: I530cefc1ca96d315c8be9b2e1337a09c349b9eb5
Signed-off-by: Ilia Petrov <il.petrov@maxima-int.com>
(cherry picked from commit 3bd2786072c1c8f4e078a6bd420483f6732697f9)
|
|
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)
|
|
Change-Id: Icf7b5877f6865191f7b80d903608a6f7d5962527
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.
Until the requirements repository has as stable/2026.1 branch, tests will
continue to use the upper-constraints list on master.
Change-Id: I9d22724bd365457a07ce146bcc16482fb6017b2e
Signed-off-by: OpenStack Release Bot <infra-root@openstack.org>
Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/functions
|
|
Change-Id: I1c4545eaa0d2ddd5e73034e4592f0063c20b8c26
Signed-off-by: OpenStack Release Bot <infra-root@openstack.org>
Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/functions
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
Assisted-By: Claude Sonnet 4.6
Change-Id: If6f09c727bc5c7af27786cdc92c998d653dd4ad1
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
