Since the configuration file of the panko module was referenced as a
variable during the deployment of the ceilometer module, the
project_name variable of the ceilometer module was overwritten,
resulting in an error when deploying the ceilometer module using the
development mode. This patch will fix this problem.
Change-Id: I90d2380b610d3caa988ee667e7c42511d3bbd937
Closes-Bug: #1795770
Various ceph-related tasks were missing a 'become' that would allow them
to work as a non-root user. This seems to only cause a problem after an
initial deployment, perhaps due to the recursive ownership & permissions
changes at the end of the ceph.yml and external_ceph.yml files.
This change adds the necessary becomes.
Change-Id: I887c7b3bdef49db1dd1bf9e5bdbf5dc47b7f41af
Closes-Bug: #1795125
Cinder has dropped [1] support for legacy backup services. It is now
necessary to specify the full class of the backup driver, rather than
just the module name. This was causing the kolla-ansible ceph jobs to
fail.
[1] https://review.openstack.org/#/c/595372
Change-Id: Icf0ee475ba73f013d4266332d999362651d9475b
When editing external bridge configuration and running a reconfigure
on openvswitch, handler "Ensuring OVS bridge is properly setup"
needs to run, but doesn't.
This moves the task from handlers to own file and always includes it
after running the handlers.
Change-Id: Iee39cf00b743ab0776354749c6e162814b5584d8
Closes-Bug: #1794504
The firewall section has been renamed in upstream ironic inspector:
7b27585463
Consequently the iptables pxe filter does not work if the actual
dnsmasq interface name differs from the default (br-ctlplane), as can
be seen from this snippet of iptables-save output:
-A INPUT -i br-ctlplane -p udp -m udp --dport 67 -j ironic-inspector
Change-Id: Ic1d08b85e0b5992fbee489f2f9fd174982b5d493
Following by https://review.openstack.org/#/c/605097/
These were used by now-dead tooling. We can remove them.
Change-Id: I0953751044f038a3fdd1acd49b3d2b053ac4bec8
Monasca is not yet compatible with InfluxDB > 1.1.10, which means
that the official Ansible modules for managing InfluxDB don't work [1].
We therefore fall back to manual commands to register the database
and a default retention policy.
[1] https://github.com/influxdata/influxdb-python
#influxdb-pre-v110-users
Partially-Implements: blueprint monasca-roles
Change-Id: I59ceda1e7a6e945b13872089011045db04548b94
This is required for upcoming log query support and it also
causes an error in the Keystone middleware if it's missing.
Partially-Implements: blueprint monasca-roles
Change-Id: I2bcb32bc0c079c799d2b0e45a97b454d38896986
On a single node deployment, the Monasca persister can
limit the rate at which Monasca can persist metrics to
InfluxDB. Increasing the thread count can remove this
bottle neck.
Partially-Implements: blueprint monasca-roles
Change-Id: I763a5ae6aa8c8ab3bf766ab5b58c386da74a188b
The Monasca Persister reads metrics from Kafka and stores them
in a configurable time series database.
Change-Id: I8166b32bfb1583098ab8318a5f38d25bddb81e89
Partially-Implements: blueprint monasca-roles
The Monasca Notification engine generates alerts such as Slack
notifications from alerts.
Change-Id: I84861d5feefe6b6f38acc4dd71e94c386d40b562
Partially-Implements: blueprint monasca-roles
Monasca Thresh is a Storm topology which generates alerts from
metric streams according to alarms defined via the Monasca API.
This change runs the thresholder in local mode, which means that
the log output for the topology is directed to stdout and the
topology is restarted if the container is restarted. A future
change will improve the log collection and introduce a better
way of the checking the topology is running for multi-node
clusters.
Change-Id: I063dca5eead15f3cec009df62f0fc5d857dd4bb0
Partially-Implements: blueprint monasca-roles
Storm is required for running the Monasca thresholder component for
generating alerts.
Change-Id: I5e1ef74dc55a787293abbb3e629b5ab1ce5f4bbb
Partially-Implements: blueprint monasca-roles
Barbican API uses uWSGI, which by default writes out log files using
0640 permissions and default ownership for the user. This means that the
log file in /var/log/kolla/barbican/barbican-api.log is not readable by
fluentd.
This was tested via the following command on a queens deployment:
$ docker exec -it fluentd bash
find /var/log/kolla/ -type f | while read f; do test -r $f || echo
"Cannot read $f"; done
Cannot read /var/log/kolla/barbican/barbican-api.log
Generally there are a few ways in which access is provided to log file
for fluentd:
1. Set log file ownership to $USER:kolla, permissions to 0640.
2. Set log file ownership to $USER:$USER, permissions to 0644.
3. MariaDB is a special case, and uses 0640 with the fluentd user added
to the mysql group.
Of these, 1. seems the most secure.
This change uses the --logfile-chmod argument to set the log file
permissions to 644, since it does not appear possible to specify a group
to change ownership to using --logfile-chown. We use command line
arguments since putting the option in the config file does not seem to
work. Perhaps it is an ordering issue.
Change-Id: If98ca7cd9630b5622132a00718cb09304b8285b3
Closes-Bug: #1794472
Having all services in one giant haproxy file makes altering
configuration for a service both painful and dangerous. Each service
should be configured with a simple set of variables and rendered with a
single unified template.
Available are two new templates:
* haproxy_single_service_listen.cfg.j2: close to the original style, but
only one service per file
* haproxy_single_service_split.cfg.j2: using the newer haproxy syntax
for separated frontend and backend
For now the default will be the single listen block, for ease of
transition.
Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
The log metrics service generates metrics from log messages
which allows further analysis and alerting to be performed
on them. Basic configuration is provided so that metrics
are generated for high level warning logs such as error, or
warning.
Change-Id: I45cc17817c716296451f620f304c0b1108162a56
Partially-Implements: blueprint monasca-roles
