Age | Commit message (Collapse) | Author | Files | Lines |
|
We need to test gnocchi with swift backend. So adding
telemetry to scenario002 job to cover that.
Change-Id: I284de61bbefac9e9b37390650016643ffe38b5cc
|
|
We install redis if its not already there, but we should also
ensure redis service is started in the next step 4.
related to issues we're seeing in I284de61bbefac9e9b37390650016643ffe38b5cc
Change-Id: Ic01db53ea8669f14e87f6987045b2be5a3480024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds this into the tripleo_upgrade_node.sh executed by the
operator for the major upgrade see the bug for more info
Change-Id: Ic54b48b149594e8ea08e95152111bcdaf7b252b7
Closes-Bug: 1707926
|
|
metadata_settings is meant to have a specific format or be completely
absent. Unfortunately the hook [1] doesn't an empty value for this. So
we remove it as an easy fix before figuring out how to add such a
functionality to the hook.
[1] https://github.com/openstack/tripleo-heat-templates/blob/master/extraconfig/nova_metadata/krb-service-principals.yaml
Co-Authored-By: Thomas Herve <therve@redhat.com>
Change-Id: Ieac62a8076e421b5c4843a3cbe1c8fa9e3825b38
|
|
|
|
|
|
These are needed for the TLS everywhere bits.
Change-Id: I81fcf453fc1aaa2545e0ed24013f0f13b240a102
|
|
|
|
With OvS2.7, DPDK is initialized immediately after setting
dpdk-init flag. DPDK requires hugepages configuration to be
available on kernel args with a reboot. This patch reboots
the node after applying the kernel args. And once the node
is rebooted, DPDK will be enabled and then the deployment
continues.
Change-Id: Ide442e09c2bea56a38399247de588e63b4272326
|
|
|
|
|
|
|
|
Running puppet apply with --logdest syslog results in all the output
being redirected to syslog. You get no error messages. In the case where this fails, the subsequent debug task shows nothing useful
as there was no stdout/stderr.
Also pass --logdest console to docker-puppet's puppet apply so that
we get the output for the debug task.
Related-Bug: #1707030
Change-Id: I67df5eee9916237420ca646a16e188f26c828c0e
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
|
|
|
|
Presently the ovn-controller service (puppet/services/neutron-compute-plugin-ovn.yaml)
is started only on compute nodes. But for the cases where the controller nodes
provide the north/south traffic, we need ovn-controller service runninng in controller
nodes as well.
This patch
- Renames the neutron-compute-plugin-ovn.yaml to ovn-controller.yaml which makes more
sense and sets the service name as 'ovn-controller'.
- Adds the service 'ovn-controller' to Controller and Compute roles.
- Adds the missing 'upgrade_tasks' section in ovn-dbs.yaml and ovn-controller.yaml
Depends-On: Ie3f09dc70a582f3d14de093043e232820f837bc3
Depends-On: Ide11569d81f5f28bafccc168b624be505174fc53
Change-Id: Ib7747406213d18fd65b86820c1f86ee7c39f7cf5
|
|
Running puppet apply with --logdest syslog results in all the output
being redirected to syslog. You get no error messages. In the case where
this ansible task fails, the subsequent debug task shows nothing useful
as there was no stdout/stderr.
Also pass --logdest console to puppet apply so that we get the output
for the debug task. My local testing showed that when specifying logdest
twice, both values were honored, and the output went to syslog and the
console.
Change-Id: Id5212b3ed27b6299e33e81ecf71ead554f9bdd29
Closes-Bug: #1707030
|
|
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 iscsid service definition has a typo, config_setting should
read config_settings
Change-Id: I12605dba61fd5f6ce80c3ab78e883ed5ebf3ca62
|
|
|
|
|
|
This sets the SSL flag in the docker service and expose the parameter in
the docker service.
Depends-On: I4c68a662c2433398249f770ac50ba0791449fe71
Change-Id: Ic3df2b9ab7432ffbed5434943e04085a781774a0
|
|
|
|
|
|
|
|
|
|
|
|
Add docker profiles to deploy Ceph in containers via ceph-ansible. This is
implemented by triggering a Mistral workflow during one of the overcloud
deployment steps, as provided by [1].
Some new service-specific parameters are available to determine the workflow to
execute and the ansible playbook to use. A new `CephAnsibleExtraConfig`
parameter can be used to provide arbitrary config variables consumed by `ceph-ansible`.
The pre-existing template params consumed up until the Pike release to
drive `puppet-ceph` continue to work and are translated, when possible, into
the equivalent `ceph-ansible` variable.
A new environment file is added to enable use of ceph-ansible;
the pre-existing puppet-ceph implementation remains unchanged and usable
for non-containerized deployments.
1. https://review.openstack.org/#/c/463324/
Change-Id: I81d44a1e198c83a4ef8b109b4eb6c611555dcdc5
|
|
|
|
|
|
|
|
The necessary resource registry entries were missing from this env
and the old environment was not deprecated.
Change-Id: I6a9b148514fc5da1f96b9fd7fe09f564c2f82419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The introduction of I90253412a5e2cd8e56e74cce3548064c06d022b1 broke the HAproxy
service due to some HAproxy-specific iptables rules being executed during the
puppet config step.
Ensure that no iptables call is performed during the generation of configuration
files. Move those calls to step 1, as implemented in the pacemaker-based
HAproxy service (Ib5a083ba3299a82645f1a0f9da0d482c6b89ee23).
Depends-On: I2d6274d061039a9793ad162ed8e750bd87bf71e9
Closes-Bug: #1697921
Change-Id: Ica3a432ff4a9e7a46df22cddba9ad96e1390b665
|
|
This is currently included in the controller-role template, so we need
to add it to the generic role.role.j2.yaml in order to convert the
controller-role template to be rendered via j2
Change-Id: I01bf01c8a31e4cc26f202dd1774845ec33f50bcd
Partially-Implements: blueprint composable-networks
|
|
|