In I780103e17f1bb42a0546c30bd6c001c642ad88b3 we introduced the
journald default for the events_logger key. With this change we
allow to change this new default, in case we do need to change it
for some reason.
Related-Bug: #1923607
Depends-On: https://review.opendev.org/c/openstack/tripleo-ansible/+/794485
Change-Id: Ieffe2852111c3ec8347343a042dd78bbf691d79a
Jinja2 rendering failed when using network-v2 format
because the network_data yaml does not include the
ip_subnet key at the network level.
Default network.ip_subnet to "" in the places were it
does not have a the default already.
These templates are not used with network-v2.
Closes-Bug: #1929835
Change-Id: Ib4d0551d99afd55fbb513f8c5050fb835dc332b4
This patch updates cinder's kolla permissions so that cinder can
access any cephx keyring associated with CephExternalMultiConfig
ceph clusters. The new approach parses the cluster names out of the
CephExternalMultiConfig array, and uses a wildcard to grant access
to all keys (regardless of the key name) defined for each cluster.
There is no risk of the wildcard granting improper access to a
privileged key (e.g. the admin key), because CephExternalMultiConfig
doesn't include privileged keys.
This patch replaces similar (but more restrictive) code added in
I73af5b868de629870a35d38f8436e7025aae791e. That patch allowed cinder
to access cephx keyrings associated with a new CinderRbdMultiConfig
parameter, but it didn't cover all potential use cases. For example,
in a DCN/Edge deployment, cinder services running at the edge need
access to the central site's client key in order to perform operations
like offline volume migration.
Closes-Bug: #1930620
Resolves: rhbz#1962304
Change-Id: I4423fcbd62b09ef323590fc740dd29e1a17777f5
Tunnelled migration is not compatible with post_copy as pointed by the
related BZ. It was disabled up until we fixed the puppet namespace in
I845bc3c533e55dd5398d6a74ee48762cfd32b8a9
Closes-bug: 1930599
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1967130
Change-Id: Ia1a03cf798436b5f9865b527a8c742d13bbff180
As we use PATCH update if we remove these resources
from default resource registry the existing mappings
would still be there in the stack environment. Map
them to OS::Heat::None instead.
Depends-On: https://review.opendev.org/c/openstack/python-tripleoclient/+/793909
Change-Id: I526dff594543df025215c6af476be46e948c9fe5
The unbound resolver template and related code was not added to scenario
003 triggers. This patch temporarily removes the unbound resolver to be
added once the triggers land.
Change-Id: I491785af24a780bc75476b4c55ff458c8375dda5
When Ceph is external, we can use [1] to deploy standalone ganesha
instances; these instances can be connected to the external ceph
cluster via the related ceph.conf and keyrings.
[1] https://review.opendev.org/786871
Depends-On: Ied85643d888d6729aa97172d836c8d1e04bb469f
Change-Id: Ib5f83f7fcbf7ecbbbea41a62275970d13d589ae8
Traditionally, Ganesha consumes /etc/idmapd.conf, which controls
mapping of user/owner identities under NFSv4+. With containerized service
deployment, this file has beenan immutable part of the container image
and could not be modified.
Recently ceph-ansible was modified to allow the user to set the path
for idmapd.conf and to override ini settings in this file by supplying
json configuration for the overrides in the same way that it can be
supplied for ceph.conf overrides [1]. Also, the default path setting
for the idmapd.conf file is /etc/ganesha/idmap.conf, which already is
reflected into containerized ganesha under /etc/ganesha, solving the
immutability issue. If no overrides are supplied, the file put in this
location will match that originally frozen into the container, so there
is no issue here with backwards compatibility.
This change exposes parameters for idmap.conf file path and override
contents in TripleO and passes them into ceph-ansible. It also sets up
these parameters for cephadm. Cephadm support for OpenStack Ganesha
is WIP so there will likely need to be a followup patch to make these
effective when cephadm replaces ceph ansible.
[1] https://github.com/ceph/ceph-ansible/pull/6422
Change-Id: I422e49f0027efbbb25256d8b4718eb0aa78d90a4
The VLAN key needs to be nested under the subnet
dictionary. Otherwise they will fail the schema validation
during network deployment.
This changes moves them in all examples to the subnet
dictionaries in each file.
Closes-Bug: #1930316
Change-Id: I0a73443630faf25de870a7878a9568ac8319aee9
This environment allows us to control the external VIP for Undercloud or Standalone SSL.
When used, a network data has to be provided (e.g. network_data_undercloud.yaml) and
`openstack tripleo deploy` must be called with --public-virtual-ip.
It's not really needed for Undercloud because
environments/undercloud.yaml already sets the resource right, but for
Standalone users this file will be useful when they want public
endpoints to be listening on another network.
Change-Id: I461e0fdc8fc717beed3aea7a66e41de1e11116da
New parameter to control RBD disk caching modes.
Depends-On: https://review.opendev.org/792326
Change-Id: I6fac9ff39892c08453c050816f61a4bcee4bddf0
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
This change breaks the deploy-steps monster playbook into isolated playbook
files allowing us to use the deploy-steps entrypoint as a playbook router.
With this change we'll be able to further optimise our playbook processes
in isolation and begin exploring different methods of deployment for parts
of our stack. Additionally this change will make it possible for advanced
users to run playbooks as needed, without having to run everything from
top to bottom.
Change-Id: I34bb41e63ccc65ae47999758ab7ce8a6120ef0a4
Signed-off-by: Kevin Carter <kecarter@redhat.com>
The legacy parameters (e.g InternalApiNetCidr) default to the new
network_data.yaml values.
When ManageNetworks: true the value of these parameters is then used to
create the network resources. The cidr attribute of the resources are
then used to build the network_cidrs output value resulting in the
correct list of cidrs.
However when Managenetworks: false the resources are not created so an
alternative approach is required. Currently only the values from
network_data.yaml are used. If the legacy parameters are being used in
a deployment this will result in the cidrs from the default
t-h-t/network_data.yaml instead of the values from the heat parameters.
This can result in live migration failure as the firewall subnet is
incorrect on compute nodes.
To resolve this we can just use the value from the legacy params to
build the cidr list when ManageNetworks: false. There is also an
unnecessary list_concat which can be removed.
Closes-bug: 1929470
Change-Id: Ibe5f9ec4dc32a6e8277e95032e608209a035cad5
Zuul