1) Rename the neutron DB at step 2 so Neutron has time to stop (during
step 1) and right after we stop mariadb, so no chance for any app to
access to old db.
2) Upgrade all rpms at step 3 like we do for other services. Step 1 was
way too early.
Change-Id: I34bdc0a9d575e5d1b8f3ce1e09c145cc34563a85
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
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
During major upgrade of non-HA overcloud, paunch stops the
containerized mysql service, update container image and restart
the containerized mysql.
After a major update of mysql (e.g. 5.5 to 10.0), run mysql_upgrade
to ensure that database on-disk is upgraded to match the mysql
server version (e.g. update all MyISAM tables)
The mysql_upgrade cannot be performed during upgrade_steps because
paunch only runs during the deploy_steps. So run it in the
post_upgrade_steps, once we know paunch has updated mysql.
Change-Id: I6b6a531fd716ad9abcbf29886c0b1f2c64f04c9d
When the undercloud was not containerized, the neutron database name was called neutron.
When we upgrade to a containerized undercloud, the database name is called ovs_neutron.
We introduced MigrateLegacyNeutronDb (false by default in the service but true when
the undercloud is containerized) that will rename the database during host_prep_tasks.
Also, we'll make sure mariadb is stopped before running Puppet steps,
but only when we deploy a containerized undercloud and also when mariadb
was actually running. The tasks are idempotent and tested.
Change-Id: I009cd38f4d10bf3942c8f18f90c6a0fa50858219
Closes-Bug: #1753247
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 patch reverts the revert of Redis TLS [1,2], and update the
pacemaker redis template to configure Redis to encrypt the
replication traffic between Redis nodes.
[1] a3769c03175cb36f0066c173477749a26f767566
[2] ebc8414cd0c18426ff80d9d65c964e91a7fe447f
Depends-On: I6cc818973fab25b4cd6f7a0d040aaa05a35c5bb1
Change-Id: I7f7be4bba6d41c04385f074857c82507cc8c2617
Closes-Bug: #1737707
This patch enables health check execution for Redis docker container.
Change-Id: I631f6e1a57fe3e455ec278a3bdc8d2ec35929b8a
Depends-On: If6e4fba9da81350046630420e5bee0ee4cbd14cc
In TripleO we exported the KOLLA_KUBERNETES to skip the cluster
readiness check and workaround a limitation of the mariadb boostrap
script in Kolla that expected MariaDB 10.0 coming from the MariaDB
repository and didn't work with the MariaDB 10.1 from RDO.
Luckily this was fixed in Kolla with
Ia2acb09e877a586243fc1acb49d8d140cf27d7b5 and we can now remove this
tech debt from t-h-t.
Change-Id: Iba62e436a16ddb3cfc87fc4ec03b599e55841681
Related-Bug: #1740060
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
Lets revert the tls support until we know it works.
Revert "TLS proxy for redis"
This reverts commit c2a93cf4c5d9d6b5ee0536380751a7a9540927cc.
Closes-bug: #1735259
Change-Id: I8157ce04617c094978175f3e4b3071bdf76362fe
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
This should help operators find the new log files. We do have them
documented, but not everybody reads every word in the docs :)
The readme creation has ignore_errors: true so that if the directory
isn't present at all (e.g. on deployed server environments, which
don't have openstack packages installed), we don't fail the deployment
when we're not able to create the readme.
Change-Id: I6b36db7b7ce8b3e4da566eb7828d0c3b8646a14f
Partial-Bug: #1730957
During mysql initialization, mysql needs to be able to write in the
database directory.
Change-Id: I82c2e46f66ab01021cb910eb7e0d17c81b00fa09
Closes-bug: #1730349
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: If2720b84a5ba5c074bab19fabcb8cb25baac6af5
Partial-Bug: #1704389
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: Idf93d01521af4ae08702168d68941025cffeca44
Partial-Bug: #1704389
Currently health check for mysql container reports unhealthy container
because there is no 'mysql' user created. This patch creates the user
during mysql_bootstrap without any permission, just to allow health
check to connect to DB and run 'select 1'.
Change-Id: Iab26da0d30939b219189d4e7beb2a61d456ab7c3
Closes-Bug: #1718944
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
Patch Ie09ce2a52128eef157e4d768c1c4776fc49f2324 added a new
set of upgrade tasks which were missing the 'tags' keyword.
Change-Id: Ib1c1aadfbf58c9bccc18667934c8b3c5f38fafa4
This change removes the entry to containerise docker by default
because it should now be disabled since the change
Id2e6550fb7c319fc52469644ea022cf35757e0ce.
Removing the entry means the default mapping to mongodb-disabled.yaml
takes effect.
This change also modifies the upgrade_tasks so that the mongod service
is only disabled when the service exists. There appears to be upgrade
scenarios which fail because mongodb was never installed in the first
place.
Change-Id: Ie09ce2a52128eef157e4d768c1c4776fc49f2324
Closes-Bug: #1715031
Redis does not have TLS out of the box. Let's use a proxy container for
TLS termination.
bp tls-via-certmonger
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Change-Id: Ie2ae0d048a71e1b1b4edb10c74bc0395a1a9d5c9
Depends-On: I078567c831ade540cf704f81564e2b7654c85c0b
Depends-On: Ia50933da9e59268b17f56db34d01dcc6b6c38147
Bind mounts and adds the appropriate permissions for the cert and
key that's used for TLS.
bp tls-via-certmonger-containers
Change-Id: I7fae4083604c7dc89ca04141080a228ebfc44ac9
The containerized version of the mongodb service omits the
metadata_settings definition [1], which confuses certmonger when
internal TLS is enabled and make the generation of certificates fail.
Use the right setting from the non-containerized profile.
[1] https://review.openstack.org/#/c/461780/
Change-Id: I50a9a3a822ba5ef5d2657a12c359b51b7a3a42f2
Closes-Bug: #1709553
This bind mounts the necessary files for the mongodb container to serve
TLS in the internal network.
bp tls-via-certmonger-containers
Change-Id: Ieef2a456a397f7d5df368ddd5003273cb0bb7259
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
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
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 commit consistently defines a heat template parameter in the form
of DockerXXXConfigImage where XXX represents the name of the
config_volume that is used by docker-puppet.
The goal is to mitigate hard to debug errors where the templates would
set different defaults for the image docker-puppet.py uses to run, for
the same config_volume name.
This fixes a couple of inconsistencies on the way.
Change-Id: I212020a76622a03521385a6cae4ce73e51ce5b6b
Closes-Bug: #1699791
In many occasions we had log directory initialization containers
without `detach: false`, which didn't guarantee that they'll finish
before the container depending on them will start using the log
directory.
This is now fixed by moving the initialization container one global
step earlier, so that we can keep the concurrency when creating the
log dirs. (Using `detach: false` makes paunch handle just one
container at a time, and as such it can have negative performance
impact.)
For services which have their container(s) starting in step_1,
initialization cannot be moved to an earlier step, so the solution
here was to just add `detach: false`.
As a minor related change, cinder DB sync container now mounts the log
directory from host to put cinder-manage.log into the expected
location.
Change-Id: I1340de4f68dd32c2412d9385cf3a8ca202b48556
This service generates the /etc/my.cnf.d/tripleo.cnf file which is
being used to configured MySQL clients (e.g. client bind address,
client SSL configuration...)
We generate the config file in this service and let containerized MySQL clients
mount /var/lib/config-data/mysql_client/etc/my.cnf.d/tripleo.cnf it in their
own container. This way, when this MySQLClient service is updated, the other
containers will automatically pick the updated configuration at next restart.
Partial-Bug: #1692317
Change-Id: Idc56d27fb9645ad3b07df8ef08b7e2ce29e6d499
This change modifies these mounts to be more specific mounts based on
the files which puppet actually modifies.
The result is something a bit more self-documenting, and allows for
trying other techniques for populating /etc other than directly mounting
config-data directories.
Change-Id: Ied1eab99d43afcd34c00af25b7e36e7e55ff88e6