Services need to provide this rsyslog configuration in order for
their logs to get ingested by rsyslog for forwarding.
Closes-Bug: 1953672
Change-Id: I0da99239275fa7f53f032ca4a85460e6111738b4
(cherry picked from commit c3bb913386)
It can now be configured using a new Heat parameter:
ZaqarWsTimeout.
Depends-On: https://review.opendev.org/728974
Change-Id: I4328d4bafb556e5936793e8a58c3e19635b37406
Signed-off-by: Luke Short <ekultails@gmail.com>
Ansible tasks that invoke puppet produce excessive and barealy readable
outputs. The established pattern is to silence it and only provide a
pretty-formatted debug if the former has failed.
Also align the puppet invocation for the same configuration of
iptables pattern in I7174d687e0cf2304f7d4deab68ca392dd750c74c
Change-Id: I57038a6185a1f533b2e51257b75ed448f036514e
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Almost every single tripleo service creates a persistent directory. To
simplify the creation, a with_items structure was being used. In which
many times, the mode option was being set. However, that mode option
was not taken into account at the time of creating the file. As a
consequence, the directory was being created with its father directory
rights, instead of the ones being passed in the template.
Change-Id: I215db2bb79029c19ab8c62a7ae8d93cec50fb8dc
Closes-Bug: #1871231
Current puppet modules uses only absolute name to include classes,
so replace relative name by absolute name in template files so that
template description can be consistent with puppet implementation.
Change-Id: I7a704d113289d61ed05f7a31d65caf2908a7994a
The haproxy::crl_file was first set to 'null', then set to
the file within the same map_merge.
Remove the line setting it to 'null'.
Change-Id: I7417eecd0dda5e3bcb7fa0a9668c85bda65a385b
Related-Bug: #1860638
This patch adds the CRL directory to the haproxy in case of TLS
everywhere deployment, it also removes the duplicated CA file
from the haproxy and rabbitmq containers.
Depends-On: I836ab1a23c8aea35c0cea54d0765c7313a4b9038
Closes-Bug: #1860638
Closes-Bug: #1860641
Change-Id: I7d18befc51a4afb404b39ebdd8b1ccab4dfdf744
While they are, at SELinux level, exactly the same (one is an alias to
the other), the "container_file_t" name is easier to understand (and
shorter to write).
A second pass in a couple of days or weeks will be needed in order to
change files that were merged after this first pass.
Change-Id: Ib4b3e65dbaeb5894403301251866b9817240a9d5
Ansible has decided that roles with hypens in them are no longer supported
by not including support for them in collections. This change renames all
the roles we use to the new role name.
Depends-On: Ie899714aca49781ccd240bb259901d76f177d2ae
Change-Id: I4d41b2678a0f340792dd5c601342541ade771c26
Signed-off-by: Kevin Carter <kecarter@redhat.com>
When podman parses such volume map it removes the slash
automatically and shows in inspection volumes w/o slash.
When comparing configurations it turns to be a difference and
it breaks idempotency of containers, causing them to be recreated.
Change-Id: Ifdebecc8c7975b6f5cfefb14b0133be247b7abf0
This change converts our filewall deployment practice to use
the tripleo-ansible firewall role. This change creates a new
"firewall_rules" object which is queried using YAQL from the
"FirewallRules" resource.
A new parameter has been added allowing users to input
additional firewall rules as needed. The new parameter is
`ExtraFirewallRules` and will be merged on top of the YAQL
interface.
Depends-On: Ie5d0f51d7efccd112847d3f1edf5fd9cdb1edeed
Change-Id: I1be209a04f599d1d018e730c92f1fc8dd9bf884b
Signed-off-by: Kevin Carter <kecarter@redhat.com>
When upgrading from Rocky to Stein we moved also from using the docker
container engine into Podman. To ensure that every single docker container
was removed after the upgrade a post_upgrade task was added which made
use of the tripleo-docker-rm role that removed the container. In this cycle,
from Stein to Train both the Undercloud and Overcloud work with Podman, so
there is no need to remove any docker container anymore.
This patch removes all the tripleo-docker-rm post-upgrade task and in those
services which only included a single task, the post-upgrade-tasks section
is also erased.
Change-Id: I5c9ab55ec6ff332056a426a76e150ea3c9063c6e
We switched to containers a long time ago. This patch drops the
management of a /var/log/<service> directory and the creation of a
readme indicating that we've moved to containers which makes the logging
available under /var/log/containers/<service>
Change-Id: Ia4e991d5d937031ac3312f639b726a944743dd1e
We should ensure that the service folders are 0750. We're setting
/var/log/containers but we should also ensure the service folders also
have the correct permissions.
Change-Id: I28e8017edc7e30a60288adf846da722fd6ab310e
Create a new Rsyslog service that is deployed on the host (not in a
container) and with Ansible.
Make it so it's deployed by default on Undercloud & Standalone setups.
Also move the tasks that configure rsyslogd for HAproxy & Swift to be
executed after the host prep tasks (using deploy step tasks).
Change-Id: I027c64aefcc4715da17836a5cf0141152cf146aa
Closes-Bug: #1850562
Moving all the container environments from lists to dicts, so they can
be consumed later by the podman_container ansible module which uses
dict.
Using a dict is also easier to parse, since it doesn't involve "=" for
each item in the environment to export.
Change-Id: I894f339cdf03bc2a93c588f826f738b0b851a3ad
Depends-On: I98c75e03d78885173d829fa850f35c52c625e6bb
We are missing some step tags in updates/upgrades/ffu
tasks to make the Ansible lint check to work.
Change-Id: I7eb07d6b0b3738c63184ab5b900bbf1b2d62da8f
Before we start services on upgraded bootstrap
controller (usually controller-0), we need to
stop services on unupgraded controllers
(usually controller-1 and controller-2).
Also we need to move the mysql data transfer
to the step 2 as we need to first stop the
services.
Depends-On: I4fcc0858cac8f59d797d62f6de18c02e4b1819dc
Change-Id: Ib4af5b4a92b3b516b8e2fc1ae12c8d5abe40327f
The tripleo-docker-rm role has been replaced by tripleo-container-rm [0].
This role will identify the docker engine via the container_cli variable
and perform a deletion of that container. However, these tasks inside the
post_upgrade_tasks section were thought to remove the old docker containers
after upgrading from rocky to stein, in which podman starts to be the
container engine by default.
For that reason, we need to ensure that the container engine in which the
containers are removed is docker, as otherwise we will be removing the
podman container and the deployment steps will fail.
Closes-Bug: #1836531
[0] - 2135446a35
Depends-On: https://review.opendev.org/#/c/671698/
Change-Id: Ib139a1d77f71fc32a49c9878d1b4a6d07564e9dc
This converts all Docker*Image parameter varients into
Container*Image varients.
The commit was autogenerated with the following shell commands:
for file in $(grep -lr Docker.*Image --include \*.yaml --exclude-dir releasenotes); do
sed -e "s|Docker\([^ ]*Image\)|Container\1|g" -i $file
done
Change-Id: Iab06efa5616975b99aa5772a65b415629f8d7882
Depends-On: I7d62a3424ccb7b01dc101329018ebda896ea8ff3
Depends-On: Ib1dc0c08ce7971a03639acc42b1e738d93a52f98
a) The haproxy.stats stanza in haproxy config file has pretty much remained the same since newton:
listen haproxy.stats
bind 192.168.24.8:1993 transparent
mode http
stats enable
stats uri /
stats auth admin:tRJre6PnQuN4ZwqKYUygTJArB
b) what we do today with the haproxy stats makes little sense:
- we bind it to the VIP running on the control-plane network on all controller nodes
- de facto we allow to look at the haproxy stat info via web only on the node holding the ctlplane VIP
- since haproxy does not share stats across nodes, we're effectively
limited at looking at the stats info on a single node.
Now imagine ctrl-0 holding the internal_api VIP and ctrl-1 holding the
ctlplane VIP. Basically now the only stats you will be able to see are
the ones relative to keystone_admin (which for other silly reasons has
been moved to ctlplane by default) and very little else.
Tested this and am able to bind the haproxy stat to another network
and to have it listen to the IP of the node on said network (in addition
to the ctrlplane vip which we do not remove as it might break stuff):
listen haproxy.stats
bind fd00:fd00:fd00:2000::16:1993 transparent
bind 192.168.24.15:1993 transparent
mode http
stats enable
stats uri /
stats auth admin:password
Closes-Bug: #1830334
Depends-On: Iab5f11c3065ff34a3543621554e7f05161d069f2
Change-Id: If2ee15f1e0fcf6d077cba524fad75dec7e1144b6
The problem we want to selve is that the change
https://review.opendev.org/#/c/631486/ (moving iptables creation to the
host) never really worked.
The reason it never worked and we never noticed is two-fold:
A) It ran: -e include ::tripleo::profile::base::haproxy
the problem is that without quoting puppet basically does a noop
B) Once the quoting is fixed it breaks because 'export FACTER_step'
exports a custom fact but does not export a hiera key per-se (so calls
to hiera('step') would fail
So we add proper quoting only on the variables that are arguments to a
parameter so that there is no risk of ansible doing the wrong thing and
puppet gets the correct arguments.
We also explicitely set the step for hiera in the deploy_steps_tasks.
The reason we need it is because in non-HA the iptables rules would
be created at step 1. But since the deploy_steps_tasks run before the
actual tasks that set the step hieradata.we would get the following
error:
Error: Function lookup() did not find a value for the name 'step'
We can just write out the step hiera key during the deploy_steps_tasks,
it will be enforced again shortly afterwards once the
common/deploy-steps-tasks.yaml gets invoked.
We also switch back to puppet_execute: ::tripleo::profile::base::haproxy
even for the pacemaker profile. This was broken by the flattening of the
haproxy service (Id55ae44a7b1b5f08b40170f7406e14973fa93639)
Co-Authored-By: Luca Miccini <lmiccini@redhat.com>
Change-Id: Iab310207ca17a6c596470dda30a39e029c4fe09c
Closes-Bug: #1828250
When we're in "--check" mode with Ansible, the variable is defined,
but its content doesn't match the one we might get when actually applying
the run.
The right way to detect that is to check if the variable is changed.
In "--check", it is not changed, meaning we can't get the "rc" attribute.
I5851dc7820fdcc4f5790980d94b81622ce3b0c8d didn't do the right check, and
does not improve the situation.
Change-Id: I77c655addd0fe01948584fb43ba24d5b24ff330e
Related-Bug: #1823841
Introduced with Ia615ac07d0c559deb65e307bb6254127e989794d, an issue
can be hit when deploy is launched with dry-run mode.
Change-Id: I5851dc7820fdcc4f5790980d94b81622ce3b0c8d
Related-Bug: #1823841
UpgradeRemoveUnusedPackages is not used anymore. All packages are
supposed to be removed on undercloud upgrade to 14.
Change-Id: Ie6b739390ec0ae0c5773a5a6c63b49422195623a
This change combines the previous puppet and docker files into a single
file that performs the docker service installation and configuration.
With this patch the baremetal version of haproxy services has been removed.
Change-Id: Id55ae44a7b1b5f08b40170f7406e14973fa93639
Related-Blueprint: services-yaml-flattening
Calling iptables CLI in the container requires advanced and risky
bind-mounts, and on certain platform, iptables-save can't be found (e.g.
fedora28 containers).
This patch simplifies the firewall step for HAproxy container
configuration where we now run Puppet on the host instead of from the
container.
Note: we can't use the puppet module in Ansible yet because we need
Ansible 2.7.6 which has:
8606fb33f0
In the meantime, we use shell.
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
Co-Authored-By: Emilien Macchi <emilien@redhat.com>
Co-Authored-By: Cédric Jeanneret <cjeanner@redhat.com>
Change-Id: Ia66db8e4ab0ccec7cc86665e2ad32d2861fe30c8
We have non fatal errors in the upgrade
jobs execution if the logs folder is not
created when adding the readme.txt file
to clarify the possible locations of
the logs.
Closes-Bug: 1811708
Change-Id: Ibc0a266bdc6630eaf34bfadeff21f7bd72fa75ad
Haproxy 1.8 brings in a specific change that breaks us:
It removes the haproxy-systemd-wrapper which
we use in order to be able to reload the config file without
restarting the whole container (important in TLS scenarios).
We fix this by calling the haproxy binary directly and
using the master-worker mode (-Ws) which allows to receive
a SIGUSR2 command which will then reload the config for
all the workers. It should also not background.
This commit keeps backward compatibility with current HAProxy
to ease the transition to new HAProxy.
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
Change-Id: I93943efefa22b9107c85f9f5e0bd4c3c1ab867ed
In order to allow the system iptables to actually run from within a container,
we might need specific, per-kernel modules in order to avoid mismatches.
Currently, the only container having the system iptables mounted is the
haproxy_firewall thingy.
Change-Id: Idabc2da14413d953c8fe9effdd240dc250e7c64d
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1665598
Since haproxy logs are managed by rsyslog, we want to ensure this
service can actually write in the location.
This means we have to ensure haproxy/* is set to var_log_t, and NOT
the usual svirt_sandbox_file_t context.
Change-Id: Ica897c186268461f8f90cca4d417794d9b7dedad
Currently we don't use relabeling of the folder when SELinux is enabled.
This leads to the fact that we can not update the configuration of
haproxy during the update, because of missing permissions.
This commit adds the relabeling for the folder, which allows the
container with haproxy to write into it.
Closes-Bug: #1807933
Change-Id: Ie79aed5f5665658ea09e000a4847062e9207e25c
With the current configuration, HAProxy logs are in the host journal.
This isn't really friendly when you want to debug issues with this service.
This patches ensures HAProxy logs are in a dedicated file, using the syslog
facility set in its configuration.
Depends-On: I8fee040287940188f6bc6bc35bdbdaf6c234cbfd
Change-Id: Ia615ac07d0c559deb65e307bb6254127e989794d
We don't need upgrade_tasks that stop systemd services since all
services are now containerized.
However, we decided to keep the tasks that remove the rpms in case some
of deployments didn't cleanup them in previous releases, they can still
do it now.
Change-Id: I6abdc9e37966cd818306f7af473958fd4662ccb5
Related-Bug: #1806733
For all containers where restart=always is configured and that are not
managed by Pacemaker (this part will be handled later), we remove these
containers at step 1 of post_upgrade_tasks.
Change-Id: Id446dbf7b0a18bd1d4539856e6709d35c7cfa0f0
This has been unused for a while, and even deprecation was scheduled
(although the patch never merged [1]). So, in order to stop folks
getting confused with this, it's being removed.
[1] https://review.openstack.org/#/c/543871/
Change-Id: Iada64874432146ef311682f26af5990469790ed2
Deactivating selinux separation for now will allow haproxy to access
its certificate without any issue.
Change-Id: Ia00219337737dca87f745af5519effc04ce0a620
This will allow proper access from the containers without any
new SELinux policy
Depends-On: Ie9f5d3b6380caa6824ca940ca48ed0fcf6308608
Change-Id: I284126db5dcf9dc31ee5ee640b2684643ef3a066
* We don't use this setup if TLS everywhere is not enabled, so lets set it
up as such. This prevents the HAProxy container managed by pacemaker of
mounting this file.
* Also fix the docker service to exercise the if with proper syntax.
Co-Authored-By: Emilien Macchi <emilien@redhat.com>
Change-Id: Id8dff81c5af390446507bcef458a135fc2287186
This has been unused for a while, and even deprecation was scheduled
(although the patch never merged [1]). So, in order to stop folks
getting confused with this, it's being removed.
[1] https://review.openstack.org/#/c/543871/
Change-Id: Icc6b51044ccc826f5b629eb1abd3342813ed84c0
Like every other cert, this should be using the /var/lib/kolla... path,
this would copy the appropriate certificate and get it into a path where
we can subsequently get the appropraite permissions.
Change-Id: Ic262a0c398a0c8ad52695016b94c00710b0a12b3
Related-Bug: #1785059
Move HAproxy, Ironic, Keystone, Zaqar and Mistral package removals at step 3
of upgrade process, required to have a successful containerized undercloud
upgrade.
Also add missing cleanup tasks for Keepalived.
This complete the work started by Ic14f7837d8d11fd5260ba7c5236018c9a6226e5e
Change-Id: I52c3aeb1a50ef0080b5411611e3f46941840f13b
Include the tasks that are necessary when upgrading a non-containerized
undercloud to a containerized undercloud for example.
Change-Id: I1e281711f1543659e7ec043747857b756beda3e1
This is basically a rewrite of the bash script pushed by
puppet/extraconfig/tls/tls-cert-inject.yaml
UpgradeImpact: NodeTLSData is not used anymore
Change-Id: Iaf7386207e5bd8b336759f51e4405fe15114123a
The new master branch should point now to rocky.
So, HOT templates should specify that they might contain features
for rocky release [1]
Also, this submission updates the yaml validation to use only latest
heat_version alias. There are cases in which we will need to set
the version for specific templates i.e. mixed versions, so there
is added a variable to assign specific templates to specific heat_version
aliases, avoiding the introductions of error by bulk replacing the
the old version in new releases.
[1]: https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#rocky
Change-Id: Ib17526d9cc453516d99d4659ee5fa51a5aa7fb4b
This flag is on by default, and serves to enable (or disable) the
public TLS by default feature.
It differs from the PublicSSLCertificateAutogenerated flag in the fact
that it works with mistral, while PublicSSLCertificateAutogenerated
works with certmonger in the overcloud.
Change-Id: If553ecff26d5ecd529c37ca438e0ba1795e9ecca
Instead of using host_prep_tasks (which are part of deployment tasks),
we'll use the upgrade tasks that are now well known and tested in
previous releases, when the we containerized the overcloud.
Depends-On: Id25e6280b4b4f060d5e3f78a50ff83aaca9e6b1a
Change-Id: Ic199c7d431e155e2d37996acd0d7b924d14af2b7
Using host_prep_tasks interface to handle undercloud teardown before we
run the undercloud install.
The reason of not using upgrade_tasks is because the existing tasks were
created for the overcloud upgrade first and there are too much logic
right now so we can easily re-use the bits for the undercloud. In the
future, we'll probably use upgrade_tasks for both the undercloud and
overcloud but right now this is not possible and a simple way to move
forward was to implement these tasks that work fine for the undercloud
containerization case.
Workflow will be:
- Services will be stopped and disabled (except mariadb)
- Neutron DB will be renamed, then mariadb stopped & disabled
- Remove cron jobs
- All packages will be upgraded with yum update.
Change-Id: I36be7f398dcd91e332687c6222b3ccbb9cd74ad2
Chris Sibbitt
Luke Short
Bogdan Dobrelya
Jose Luis Franco Arza
Takashi Kajinami
Harald Jensås
abdallahyas
Cédric Jeanneret
Kevin Carter
Sagi Shnaidman
Alex Schultz
Emilien Macchi
Carlos Camacho
Dan Prince
Michele Baldessari
Sergii Golovatiuk
David J Peacock
Mike Fedosin
Juan Antonio Osorio Robles