Kolla-ansible provides support for the dev mode for some projects
of openstack, but there are still some projects that do not yet
support specific release tag. This patch will implement this function
for these project.
Change-Id: I917b27dd61295b542457a21b240afe2cd4e83e58
The cephx keys are missing a default permission
to allow to see blacklisted clients.
This permission ensures that in the event of a client
crash (kill -9/hard shutdown/power outage) the client
can re-connect and write to any devices after reboot.
Closes-Bug: 1773449
Change-Id: I44d3982233f892d2c0ce3b9964194d8098453978
Signed-off-by: Jorge Niedbalski <jorge.niedbalski@linaro.org>
Kolla Ansible now claims [1] to support executing as a user other than
root. We should ensure that this is tested in CI.
This change removes the 'become' from hosts in the inventory, and sets
the remote user to 'kolla', as configured via the bootstrap-servers
command. The bootstrap-servers command and other ansible commands
executed before it still need to execute as the zuul user and not as
kolla, since kolla does not exist yet.
The autogenerated SSH private key in passwords.yml is now added to the
zuul user's SSH config, such that it can SSH as the kolla user, which
has authorised this key.
[1]
https://blueprints.launchpad.net/kolla-ansible/+spec/ansible-specific-task-become
Change-Id: I8f3587e2908bc5b8889cd6fbc01981a6186d33e6
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
Set sensible defaults for replica counts and minimum insync replicas
as a function of the number of nodes in the Kafka cluster.
Partially-Implements: blueprint monasca-roles
Change-Id: Icf1dddb7dd6a64f4e5efb7dffa5ffdf0880f891f
This option doesn't actually do anything and a bug to remove
it from the Monasca API config file has been raised.
Partially-Implements: blueprint monasca-roles
Change-Id: I7ec1786b5828ab0135ca86ec040f83a6f4c78d9f
- Uses swift if swift is enabled.
- Uses ceph if ceph is enabled.
- Defaults to file if swift and ceph are enabled.
Explicitly set to swift or ceph when both are enabled.
- Include swift client detail in storage section of gnocchi conf
Change-Id: I78df9a2fbe546038e1d6df350d8db0fd9b6f6d49
If the main CI job fails before generating an ARA report, the SQLite
database file will not exist. This cases the job to fail with
POST_FAILURE, rather than FAILURE, and the following is seen in the
logs:
rsync: change_dir "/home/zuul/.ara" failed: No such file or directory
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1655) [Receiver=3.1.1]
rsync: [Receiver] write error: Broken pipe (32)
This change fixes this by checking for an SQLite database file, and only
intiating the rsync transfer if it exists.
Change-Id: I370e5bc9f137abe552918a3215a025fa61e3a0ca
