This patch adds two new parameters for deploying Barbican with the
PCKS#11 backend `BarbicanPkcs11CryptoTokenLabels` and
`BarbicanPkcs11CryptoOsLockingOk`.
The patch also deprecates `BarbicanPkcs11CryptoTokenLabel` in favor of
the new option that can be set to more than one label.
Depends-On: Iba7013dd6e1b1e4650b25cd4dd8dc1f355ceb538
Change-Id: I1c5059799f613a62a13379eb82ba516a8ed3a15a
This would not have worked before we enabled server side
env merging and also we don't set that parameter in that
environment.
Change-Id: Icd6d9a12b59cf8234edb671f0f55b4df4d342d7e
Currently there is a known issue[1] in snapshot feature of cinder nfs
backend, which causes data corruption in several cases.
This change makes the feature disabled by default to require some
consideration by users before enabling the feature.
Note that this change makes the default value in Tripleo consistent
with the one(False) in cinder, so also fixes the inconsistency about
the default values.
[1] https://bugs.launchpad.net/cinder/+bug/1860913
Related-Bug: #1860913
Closes-Bug: #1896324
Change-Id: I12b8a01d0b28fed66be8ae0b1723dd89f6dc00ff
For configuring high availability for LDAP in keystone one
needs to edit /etc/openldap/ldap.conf. This worked
before control plane was containerised. Mounting the
openldap configuration into the keystone container
restores the previous behavior.
Change-Id: Id0d73a8ab0ddf7bf9e2b76ea14ffc9acff3a0ad3
Closes-Bug: #1923048
Resolves: rhbz#1944466
Previously we managed to get away with starting FRR during deployment
tasks at step1. This worked because puppet config tasks (which need
all nodes to be reachable due to pacemaker) ran after deployment step
task 1. In our testing also TLS-E setups worked okay, but that was
likely mainly due to coincidence because the IPA registration tasks
were also run at step1 of the deployment tasks and came after FRR.
FRR is needed to be up in order to reach nodes like freeipa in a BGP
based deployment.
https://review.opendev.org/c/openstack/tripleo-heat-templates/+/771832
moved IPA role from deployment_step 1 to external_deployment_step 1 and
this broke TLS-E deployments with FRR, because FRR is not up already
during external deployment step 1 and so we fail to reach the freeipa
node.
We fix this by relying on newly introduced pre_deploy_step_tasks which
are run in a separate task after container_setup_task, which is where
podman gets configured and before any deployment task.
While we're at it we also remove the state: stopped line for kolla,
which makes no sense any longer. And we also remove the main block,
since a single bunch of tasks will do it and is a bit simpler.
Tested as follows:
- Deployed an FRR-enabled TLS-E environment from master (was previously
failing 100%) a bunch of times.
Co-Authored-By: Carlos Gonçalves <cgoncalves@redhat.com>
Change-Id: I54531995fd180b3251901ff61296d6bd05fb85b2
The local certmonger cert will renew after half its lifetime, which will
be after 6 months by default. The current code would extract the CA cert
to a PEM file (and trust it), only if the cert in the existing PEM file
was expired.
But this means that the certmonger local cert could be renewed after six
months and not be replaced in the PEM file until the existing cert
expired at the end of the year. If certs are issued in this time, they
will not be trusted and the update will fail.
This patch removes this condition, so that the extracted and trusted cert
always matches what is in the PEM file, and what is trusted.
Note, this only place this occurs is on the undercloud - because this is
where we could use the certmonger local cert. We assume that the haproxy
cert will be re-issued in an update.
This change has been added to puppet-tripleo for master and all previous
releases, but in master now, we do this directly in tht as we use
ansible to get the system certs.
Change-Id: Ia0ad0ac6d7a09858b56dcb419a3bec17b63779a4
We recently changed cert generation to use linux-system roles
to generate certs instead of puppet-certmonger. However, this broke
the ability to generate the haproxy cert on the undercloud using an
IPA server, because we relied in the ability to specify the CertmongerCA
and the hieradata to provide the correct ca, principals and dns entries.
This patch restores this ability through THT template parameters.
Change-Id: Ie2e181fcd9198ae5613fde7135230d4b4cf7343d
... because kolla_start fails to start with the following error if
that environment parameter is not defined.
ERROR:__main__:InvalidConfig: KOLLA_CONFIG_STRATEGY is not set properly
Change-Id: I7cdf127b495c4d9f415a703fc8b7954a3f5b53fe
We now need to move forward and pin the newer
container-tools:3.0 stream. This will be available
on RHEL 8.4 and CentOS 8.4+.
Related: rhbz#1866479
Change-Id: I61850fa01afca92aa78412e0277180596633f858
Regressions from Ic77ed56c32c7071ce126a1528030094b97894653
and I685ec7d7c583c9f8d9f04b0f1027136ed042487c.
'if' can't be used for a key in a map. If specified for
a value the key would be ignored.
Change-Id: I0ed0d6657622100480721f7e4ca14e39944ce292
Let's introduce a new set of tasks that will be called after all the
groundwork to run containers has been run (so after podman's
host_prep_tasks, after the container_setup tasks but before any
deployment step or external deployment step).
Change-Id: If3c74703a684fbd5a815e073cc9da34e9ad672e8
Zuul
Douglas Mendizábal
John Eckersberg
ramishra
Takashi Kajinami
Grzegorz Grasza
Michele Baldessari
Ade Lee
Jesse Pretorius (odyssey4me)