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
keystone has been removed.
Related-Blueprint: services-yaml-flattening
Change-Id: I6140b02ad1ab6d88990e173dcf556977f065b3c5
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
The kolla config for the keystone container currently copies over
all of the config area using "merge". This makes sense for most of
keystone's config, but it causes a problem with the fernet keys
used for creating tokens that are stored in the config area.
Good security practices recommend keys be rotated, and keystone
and tripleo both offer the ability for an operator to trigger key
rotation. The rotation policy limits the number of previous keys
that are retained, which is 5 by default in a tripleo deployment.
The rotation all occurs on the undercloud, and the new set of keys
is provided to the keystone container via the bind mount used for
our kolla config source. Due to the use of "merge", old fernet
keys that have been deleted on the undercloud due to the rotation
policy will persist for the keystone container since "merge" skips
deletion of files.
This patch adds a second source for keystone's kolla_config, which
is used specifically for the fernet keys. The fernet key source
has "merge" set to false, and is restricted to the fernet-keys
subdirectory. This will ensure that any keys that are no longer
present in the kolla config provided by the undercloud are also not
present in the keystone container.
Change-Id: I83d1bfaba321d2fbd5cad1b8fb9478f788f5e238
Add all the keystone log files to fluentd, so
fluentd is aware of all the keystone log files
Added the new parameters to the exclusion ones
Depends-On: Ifd5fbf6509addf4a564ff83c4551525c9a139ff4
Depends-On: Id1d58637967ffb0e9bd0a83c3cbca699432f5378
Change-Id: I48c957496f7fb36d2128c545d5bcd1499e9e9bf6
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
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
Add block to step_0 for all services
Add block to step_6 for neutron-api.yaml
Add block to step_1 for nova-compute.yaml
Change-Id: Ib4c59302ad5ad64f23419cd69ee9b2a80333924e
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
Problem: RHEL and CentOS8 will deprecate the usage of Yum.
From DNF release note:
DNF is the next upcoming major version of yum, a package
manager for RPM-based Linux distributions.
It roughly maintains CLI compatibility with YUM and defines a strict API for
extensions.
Solution: Use "package" Ansible module instead of "yum".
"package" module is smarter when it comes to detect with package manager
runs on the system. The goal of this patch is to support both yum/dnf
(dnf will be the default in rhel/centos 8) from a single ansible module.
Change-Id: I8e67d6f053e8790fdd0eb52a42035dca3051999e
Add cleanup tasks for Ironic, Keystone Mistral and Zaqar, so when
upgrading an undercloud to be containerized, an operator can also
cleanup these services rpms.
Depends-On: I2af99d8bad58f12bd895b473ecb84e4f2091f738
Change-Id: I7e257cece9fa3bdd9f2d1be08ccdf5c681213149
To not to redefine variable multiple times in each service we
split httpd_enabled to per service fact set in step|int == 0 block.
Change-Id: Icea0865aadd9253ead464247bf78f45842b3a578
Since we moved services in containers, their logs aren't in the old location, but
in /var/log/containers/<service>. This patch fixes the generated Hiera hash used
by Fluentd for its configuration
Regarding Designate config service: some of the yaml doesn't use at all the
`service_config_settings` parameter - they will need to be updated accordingly
once it's supported
Co-Authored-By: Thomas Herve <therve@redhat.com>, Steven Hardy <shardy@redhat.com>
Change-Id: I1bc0930de4053dc1c34b50477e82d9ccdab7ae2e
Closes-Bug: 1769051
Related-Bug: 1674715
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
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
Ansible yum module installs all packages available in the repo
if you use asterix. We instead will use yum -y update name*.
Change-Id: I8e71367ae91faa06313711c6a954c61af705fd8f
Resolves: rhbz#1549845
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
This is necessary for certain setups (such as enabling multiple LDAP
domains). So, instead of always adding checks every time to see if
we need to refresh or not, lets just do it always, thus simplifying
the already convoluted logic here.
Change-Id: Ie1a0b9740ed18663451a3907ec3e3575adb4e778
Closes-Bug: #1748219
Co-Authored-By: Raildo Mascena <rmascena@redhat.com>
fast_forward_upgrade_tasks for keystone covering Ocata and Pike.
- Service status check
- Stop service when updating from Ocata to Pike
- Update keystone package
- Db sync
bp fast-forward-upgrades
Change-Id: I65b0c562c6e2545e99e9511d7b148c2130cc6b25
If we use variables defined in later step in conditional before
checking which step are we on we will fail.
Resolves: rhbz#1535457
Closes-Bug: #1743764
Change-Id: Ic21f6eb5c4101f230fa894cd0829a11e2f0ef39b
This converts "tags: stepN" to "when: step|int == N" for the direct
execution as an ansible playbook, with a loop variable 'step'.
The tasks all include the explicit cast |int.
This also adds a set_fact task for handling of the package removal
with the UpgradeRemovePackages parameter (no change to the interface)
The yaml-validate also now checks for duplicate 'when:' statements
Q upgrade spec @ Ibde21e6efae3a7d311bee526d63c5692c4e27b28
Related Blueprint: major-upgrade-workflow
[0]: 394a92f761/tripleo_common/utils/config.py (L141)
Change-Id: I6adc5619a28099f4e241351b63377f1e96933810
When configuring the keystone LDAP integration we need to write out
domain configuration items using the keystone_domain_config provider.
Since this tag was missed in the docker conversion, the configuration
was not actually available in the docker container.
Change-Id: I7abdfdd55e38da80768c907863fa06429debf9cd
Closes-Bug: #1737799
Step config is only required within the puppet_configs section
of docker/services/*. This patch drops the top level 'step_config'
and updates the unit tests accordingly.
Change-Id: I7dc7cfae3ef1965ec95b1d9ef23e7f162418c034
Docker services are missing the pre-upgrade validation task
in the upgrade_tasks section which verifies if the service
is running before going on with the upgrade.
Change-Id: Iee10761330311d40825f0ad11b676d8f1f20355f
Partial-Bug: #1704389
This tells the db sync to use stdout instead of a specific log file
when stdout logging is enabled
bp logging-stdout-rsyslog
Depends-On: Id9e8c641a6b00725d2f5c9623b05854a1b4e2af2
Change-Id: I25d15aac6adfab1dfd11d558404930736aace977
This adds the option to get the keystone containers to log to stdout.
The option is disabled by default.
If enabled, It also adds a sidecar container that reads the apache
access logs.
bp logging-stdout-rsyslog
Depends-On: I4250ebce75933c8fb3f85b9efdb3e2ade392a60c
Change-Id: Ibb633731a60a16d595d10d38a79ec284da18c5c2
We were setting them in the Dockerfile's previously. However this
caused the healtcheck commands to always run regardless of which
process we were running in the container. This caused 'unhealthy'
containers at times they were never intended to be checked. This
change makes it so they are explicitly set.
Change-Id: I7bc12d236b3cc7a52d3e6aa706fd04675dad3a9a
The services that docker depends on, have logging_sources and logging_groups;
but those are not set on the docker outputs so they are not used when dockers
are deployed.
Added logging_source & logging_groups as docker optional parameters in
tools/yaml-validate.py
Closes-Bug: #1718110
Change-Id: I8795eaf4bd06051e9b94aa50450dee0d8761e526
In 59e29b17f4a9f5f65b6f8a7b8e82ef6426d8a51 we forgot to
add tags to the Ansible tasks to remove the baremetal
cron jobs at step 2.
Change-Id: I23fb134b88336ebc4eb1a97a69a2d73d4ef0edb2
Related-bug: #1708466
The docker _cron services show up as (unhealthy) due to
them sharing the containers for the OpenStack services.
As such we need to manually override the health checks
for these services. By setting them to /bin/true
the services should show up has healthy.
Change-Id: I46e12bcec226fbe2768c7fe8f0e7719df46401a9
Closes-bug: #1713183
The cron containers need to run as root in order to create PID files
correctly.
Additionally, the keystone_cron container was misconfigured to
use /usr/bin/cron instead of the correct /usr/bin/crond.
Additionally we have an issue where the Kolla keystone container has
hard coded ARGS for the docker container which causes -DFOREGROUND
(an Apache specific argument) to get appended onto the kolla_start
command thus causing crond to fail to startup correctly. This
works around the issue by overriding the command and calling
kolla_set_configs manually. Once we fix this in Kolla we can
revisit this.
Change-Id: Ib8fb2bef9a3bb89131265051e9ea304525b58374
Related-bug: 1707785
Services that access database have to read an extra MySQL configuration file
/etc/my.cnf.d/tripleo.cnf which holds client-only settings, like client bind
address and SSL configuration. The configuration file is thus used by
containerized services, but also by non-containerized services that still
run on the host.
In order to generate that client configuration file appropriately both on the
host and for containers, 1) the MySQLClient service must be included by the
role; 2) every containerized service which uses the database must include the
mysql::client profile in the docker-puppet config generation step.
By including the mysql::client profile in each containerized service, we ensure
that any change in configuration file will be reflected in the service's
/var/lib/config-data/{service}, and that paunch will restart the service's
container automatically.
We now only rely on MySQLClient from puppet/services, to make it possible to
generate /etc/my.cnf.d/tripleo.cnf on the host, and to set the hiera keys that
drive the generation of that config file in containers via docker-puppet.
We include a new YAML validation step to ensure that any service which depends
on MySQL will initialize the mysql::client profile during the docker-puppet
step.
Change-Id: I0dab1dc9caef1e749f1c42cfefeba179caebc8d7
The token-flush cron job is created in /var/spool/cron/keystone
by puppet. This patch creates a cron container to run that
in an environment where it has access to keystone.conf
and the keystone-manage binaries.
Change-Id: Ie305ee9990657c66938250d1d6e19fef94675997
Partial-bug: 1701254
This removes the default container names from all the templates
and uses a single environment file to specify the full container
name and registry from which to pull. Also does away with most
of DockerNamespace.
Change-Id: Ieaedac33f0a25a352ab432cdb00b5c888be4ba27
Depends-On: Ibc108871ebc2beb1baae437105b2da1d0123ba60
Co-Authored-By: Dan Prince <dprince@redhat.com>
Co-Authored-By: Steve Baker <sbaker@redhat.com>
Makes it possible to resolve network subnets within a service
template; the data is transported into a new property ServiceData
wired into every service which hopefully is generic enough to
be extended in the future and transport more data.
Data can be consumed in service templates to set config values
which need to know what is the subnet where a deamon operates (for
example the Ceph Public vs Cluster network).
Change-Id: I28e21c46f1ef609517175f7e7ee19e28d1c0cba2
This solves a problem with bind-mounts when the containers are holding
files descriptors open.
At the same time this makes the template more robust to puppet changes
since new config files will be available in the containers without
needing to update the templates.
Partial-Bug: #1698323
Change-Id: Ia4ad6d77387e3dc354cd131c2f9756939fb8f736
This is necessary for accessing the bind mounted hieradata in the
container in order to determine if the node is the primary node.
With the new validation added to yaml-validate.py, we could spot
potential issues in sahara-api and keystone bootstrap tasks.
The keystone one is a false positive, as the image defaults to the root
user in order to be able to run apache. Still, it is better to be
consistent here and specify the root user nonetheless.
Change-Id: Ib0ff9748d5406f507261e506c19b96750b10e846
Closes-Bug: #1697917