In services which use the Apache HTTP server to service HTTP requests,
there exists a TimeOut directive [1] which defaults to 60 seconds. APIs
which come under heavy load, such as Cinder, can sometimes exceed this
which results in a HTTP 504 Gateway timeout, or similar. However, the
request can still be serviced without error. For example, if Nova calls
the Cinder API to detach a volume, and this operation takes longer
than the shortest of the two timeouts, Nova will emit a stack trace
with a 504 Gateway timeout. At some time later, the request to detach
the volume will succeed. The Nova and Cinder DBs then become
out-of-sync with each other, and frequently DB surgery is required.
Although strictly this category of bugs should be fixed in OpenStack
services, it is not realistic to expect this to happen in the short
term. Therefore, this change makes it easier to set the Apache HTTP
timeout via a new variable.
An example of a related bug is here:
https://bugs.launchpad.net/nova/+bug/1888665
Whilst this timeout can currently be set by overriding the WSGI
config for individual services, this change makes it much easier.
Change-Id: Ie452516655cbd40d63bdad3635fd66693e40ce34
Closes-Bug: #1917648
This change allows a user to forward control plane logs
directly to Elasticsearch from Fluentd, rather than via
the Monasca Log API when Monasca is enabled. The Monasca
Log API can continue to handle tenant logs.
For many use cases this is simpler, reduces resource
consumption and helps to decouple control plane logging
services from tenant logging services.
It may not always be desired, so is optional and off by
default.
Change-Id: I195e8e4b73ca8f573737355908eb30a3ef13b0d6
The Monasca alerting pipeline provides multi-tenancy alerts and
notifications. It runs as an Apache Storm topology and generally
places a significant memory and CPU burden on monitoring hosts,
particularly when there are lot of metrics. This is fine if the
alerting service is in use, but sometimes it is not. For example
you may use Prometheus for monitoring the control plane, and
wish to offer tenants a monitoring service via Monasca without
alerting and notification functionality. In this case it makes
sense to disable this part of the Monasca pipeline and this patch
adds support for that.
If the service is ever re-enabled, all alerts and notifications
should spawn back automatically since they are persisted in the
central mysql database cluster.
Change-Id: I84aa04125c621712f805f41c8efbc92c8e156db9
The Log Metrics service is an admin only service. We now have
support in Fluentd via the Prometheus plugin to create metrics
from logs. These metrics can be scraped into Monasca or Prometheus.
It therefore makes sense to deprecate this service, starting by
disabling it by default, and then removing it in the Xena release.
This should improve the stability of the Monasca metrics pipeline
by ensuring that all metrics pass via the Monasca API for
validation, and ensure that metrics generated from logs are
available to both Prometheus and Monasca users by default.
Change-Id: I704feb4434c1eece3eb00c19dc5f934fd4bc27b4
Historically Monasca Log Transformer has been for log
standardisation and processing. For example, logs from different
sources may use slightly different error levels such as WARN, 5,
or WARNING. Monasca Log Transformer is a place where these could
be 'squashed' into a single error level to simplify log searches
based on labels such as these.
However, in Kolla Ansible, we do this processing in Fluentd so
that the simpler Fluentd -> Elastic -> Kibana pipeline also
benefits. This helps to avoid spreading out log parsing
configuration over many services, with the Fluentd Monasca output
plugin being yet another potential place for processing (which
should be avoided). It therefore makes sense to remove this
service entirely, and squash any existing configuration which
can't be moved to Fluentd into the Log Perister service. I.e.
by removing this pipeline, we don't loose any functionality,
we encourage log processing to take place in Fluentd, or at least
outside of Monasca, and we make significant gains in efficiency
by removing a topic from Kafka which contains a copy of all logs
in transit.
Finally, users forwarding logs from outside the control plane,
eg. from tenant instances, should be encouraged to process the
logs at the point of sending using whichever framework they are
forwarding them with. This makes sense, because all Logstash
configuration in Monasca is only accessible by control plane
admins. A user can't typically do any processing inside Monasca,
with or without this change.
Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c
This change enables the use of Docker healthchecks for watcher
services.
Implements: blueprint container-health-check
Change-Id: I0774063dd970507e566637138167ed1af9a2874c
This change enables the use of Docker healthchecks for senlin services.
Implements: blueprint container-health-check
Change-Id: I148a0174c46244241580265d0fedc0fb1b92602c
This change enables the use of Docker healthchecks for cyborg
services.
Implements: blueprint container-health-check
Change-Id: I5326b142eaa826f97c32498cd2a9a0cba65be698
This change enables the use of Docker healthchecks for octavia services.
Implements: blueprint container-health-check
Change-Id: I2ec11544b0e9c66a1821bfe0f9a40a9e9d88033b
This change enables the use of Docker healthchecks for skydive services.
Implements: blueprint container-health-check
Change-Id: I2e18f2d912dad92a327261e092da358911531ebe
This change enables the use of Docker healthchecks for redis services.
Implements: blueprint container-health-check
Change-Id: I0590c5b22ef8eb733211b029cdd73a055d58af11
- bind health manager port to ovs
- create a octavia-interface.service (used for creating health manager
interface after reboot)
- used for ci, test or poc
Implements: blueprint implement-automatic-deploy-of-octavia
Change-Id: I8ac30dea6c8402d97189c6b05032c608936b0ff2
Co-Authored-By: wu.chunyang <wuchunyang@yovole.com>
This option disables copy of certificates from the operator host to
kolla-ansible managed hosts.
This is especially useful if you already have some mechanisms to handle
your certificates directly on your hosts.
Co-Authored-By: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Change-Id: Ie18b2464cb5a65a88c4ac191a921b8074a14f504
Deprecates support for Prometheus v1.x.
In Xena support for it will be removed from Kolla Ansible.
Change-Id: I027b19621196c698e09f79af294ba1b5dbfc0516
This change enables the use of Docker healthchecks for tacker
services.
Implements: blueprint container-health-check
Change-Id: Ib33863e4bf78f73a28d82b222ab349909ebb6671
This change enables the use of Docker healthchecks for trove services.
Implements: blueprint container-health-check
Change-Id: I55badd93f92f82e020ef80b06c788600e597d068
Currently kolla-ansible uses the same CIDR in init-run-once script
and for octavia_amp_network_cidr.
Change-Id: I5ab24fbf9be4acbd691f13d33908aa44d2b4d496
The Cinder API log is currently written to a file called
cinder-wsgi.log, and the WSGI logs to cinder-api.log. Fluentd
then tries to parse the WSGI log as an OpenStack log which
results in 'got incomplete line' errors and prevents proper
ingestion of these logs.
Co-Authored-By: yaoning <yaoning@unitedstack.com>
Closes-Bug: 1916752
Change-Id: I3296dcc4780160cbf88bd18285571276f58bb249
This commit adds possibility to deploy Neutron's DHCP agents in OVN
networking scenario.
Co-Authored-By: Michał Nasiadka <mnasiadka@gmail.com>
Change-Id: I073d04319b510182f5c1478e728c0c5bcc8799f1
This makes it possible for services to fetch the Elasticsearch endpoint
from Keystone. It is useful for both operators and Monasca Tempest.
Change-Id: Id60298582496a8959e82b970676669ca17e2e9d4
This change enables the use of Docker healthchecks for sahara
services.
Implements: blueprint container-health-check
Change-Id: I091ce194cc3180d500e287832810b499d7b100be
This change enables the use of Docker healthchecks for magnum
services.
Implements: blueprint container-health-check
Change-Id: I14d862aa599915c781d02b71a0e57d2124de9abc
it was confused to customize opts in trove-conductor.conf
or trove-taskmanager.conf now.
if we want to customize a opts,The operator needs
to know which service is using the configuration opts.
actually trove uses trove.conf is enough for all services
this change combines all trove config files.
Change-Id: I5a630109e3c4b59bff216146a3ed64c6d47e247f
It currently runs on hosts in ovn group, and in case that controllers are not
network gateways - it fails on missing openvswitch.
Change-Id: Ibbf683872337402b4e2a38323bb6a3f35ee4bed4
In I173669bdf92b1f2ea98907ba16808ca3c914944c, eswitchd.conf.j2 template
file missed a .j2 at the end. This PS rectifies it.
Change-Id: I251febe3fd192372177116569f41ccb9aa225302
