This change is intended to ease the addition of new test scenarios, by
splitting the existing setup_gate.sh script up into several smaller
scripts. We may wish to further break these scripts up in future,
depending on the requirements of new test jobs.
Change-Id: Ifa442ac79a54f749c56d20f5f7383c3852d95268
The concept of splitting the compute group into external/internal just
to specify agent_mode for Neutron DVR was deemed to be heavy handed, and
depreacated in the Pike cycle.
Now that Rocky has been released we can remove these completely for Stein.
Change-Id: I28a1eba7f40fee55a7ec41c27451e39e4d7fd8f0
If the [processing] ramdisk_logs_dir option is set, logs returned by the
ironic inspection ramdisk following hardware inspection will be stored
at that location. This enables easier debugging if inspection fails.
Change-Id: I36bdf75c04b088b67b5f54fdf20251c10bdddb63
This is a mechanically generated patch to add a unit test job running
under Python 3.6 as part of the python3-first goal.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I51f9d000469a6d92f72cc2c732b8763f35cb0c2c
The buggy come from ceph changes[0], which is included since ceph osd
v11.0.0. The `osd crush update on start` logical is moved from
`ceph-osd-prestart.sh` to ceph-osd startup process. So ceph-osd will
create buckets by node hostname automatically. Whereas, kolla is
creating buckets by node ip
For the less confused and ceph upgrade impact, disable `osd crush update
on start` is a better choice
[0] a28b71e3c9
Change-Id: Ibbeac9505c9957319126267dbe6bd7a2cac11f0c
Closes-Bug: #1801662
With a pseudo terminal, service is not treated as a daemon
and signals would not work as expected.
Change-Id: I16aa29a7924df51659d973a81d8005ae3d86f57b
Related-Bug: #1799642
The Monasca Grafana fork allows users to log into Grafana with their
OpenStack user credentials and see metrics associated with their
OpenStack project. The long term goal is to enable Keystone support
in upstream Grafana, but this work seems to have stalled.
Partially-Implements: blueprint monasca-grafana
Change-Id: Icc04613b2571c094ae23b66d0bcc38b58c0ee4e1
This changes allows the user to configure a Monasca database
which may be different from the default database.
Partially-Implements: blueprint monasca-roles
Change-Id: Ia905190b8037ecb1782a758c0b65581fe9024bf6
Monasca uses Kibana for viewing and searching logs. A future commit
will add support for the Monasca Kibana plugin to provide tenant
scoped access to logs.
Partially-Implements: blueprint monasca-roles
Change-Id: I42b6a35f9a526ef41ff3d7cfac140fbc5596a524
Before this change the HAProxy configuration for Monasca printed:
"Copying over haproxy haproxy config".
This change fixes the message.
TrivialFix
Change-Id: I2823775f6fa5b0be919b567f311c671f1469d19f
Make it easy to override the Keystone endpoints to support deploying
stand-alone Monasca which can integrate with an externally provided
Keystone instance.
Partially-Implements: blueprint monasca-roles
Change-Id: I9ae3b243c792ef88075702b47b62f164a1705c2e
This commit adds some filters which format logs so that they
can be correctly sent to the Monasca Log API by the Monasca
Fluentd plugin. In the future the Fluentd plugin could be
extended and this config could be removed.
Partially-Implements: blueprint monasca-roles
Change-Id: I87b6dfb3052d03f87349d30b66078c39d625195d
The Monasca Agent collects metrics and in this change is deployed
across the control plane. These metrics are collected into an OpenStack
project. It supports configuring a small number of plugins, which can
be extended in later commits. It also makes the Monasca Agent credentials
available to other roles, such as the common role to allow forwarding
logs to Monasca.
Partially-Implements: blueprint monasca-roles
Change-Id: I76b34fc5e1c76407a45fcf272268d5798b473ca2
The commands used by constraints need at least tox 2.0.
Update to reflect reality, which should help with local running of
constraints targets.
Change-Id: I426cebf26d4c386355fb0052ed12bda39d67fc49
Currently, the serial consoles as accessed through Horizon,
timeout after the haproxy_client_timeout (default: 1m) of
inactivity. This change allows you to set a larger timeout.
Change-Id: I2a9923cb69d5db976395146685aded83922c4120
Closes-Bug: #1800643
Apply Swift rolling upgrade based on recommendations from Swift PTL John
Dickinson at [1]
[1] https://www.swiftstack.com/blog/2013/12/20/upgrade-openstack-swift-no-downtime/
Co-Authored-By: Surya Prakash <singh.surya64mnnit@gmail.com>
Change-Id: I99f505438916be2f89b24df20506339604e5bd6e
Implements: blueprint apply-service-upgrade-procedure
This patchset implements Neutron rolling upgrade logic as described
in [1].
Due to only neutron, vpnass and fwaas have supported for rolling upgrade
database migration, so I used the list "neutron_rolling_upgrade_services"
in neutron/default/main.yml for contain there services.
[1] https://docs.openstack.org/neutron/latest/contributor/internals/upgrade.html
Co-author: Ha Manh Dong <donghm@vn.fujitsu.com>
Change-Id: I2ed2f941d30d4df0d0f42c0d10e7ca03ec1c166a
Implements: blueprint apply-service-upgrade-procedure
move the merge_yaml and merge_config module's DOCUMENTATION and
EXAMPLES into action_plugins.
Change-Id: I84c5b94afb870fc9a25838782389f7b1f8b882fd
Closes-Bug: #1799236
A small number of services set the recurse flag when they create
their config directory. This can change permission of files within
the directory, which are later set back to the original state. The
side effect is that the service is then restarted, even though the
net change to the config files amounts to nothing. The expected
behaviour is that a service only restarts if the config *has*
changed. This patch fixes this issue.
Change-Id: Ib6f1ca7b416247f8d455fb25892f4a3b27de03ba
Closes-Bug: 1800480
