If ceph-nfs (ganesha) service is enabled, it's set up by ceph-ansible
and it can be used as a manila backend. Manila can be configured to use
ceph either directly (manila-cephfsnative-config-docker.yaml env file)
or through ganesha (environments/manila-cephfganesha-config-docker.yaml
env file).
Change-Id: Ib408c7827e5fba0c1b01388db26363806fc64370
Partially-Implements: blueprint nfs-ganesha
Fix mismatches for templates for pacemaker vs docker
control planes
Change-Id: I796ae972dcfe0907025c5ecc4d0e48c15d6f5d68
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
There are some configuration applies that we need to do during the
deployment. These currently live as manually constructed bash runs which
are missing the --detailed-exitcode handling to know when we have
failures. In order to reduce the duplicated code and simplify this
exeuction, this change creates a docker_config_scripts with
docker_puppet_run.sh in containers-common that can be reused by any of
the docker services. This allows use to properly handle
--detailed-exitcodes while also reducing the amount of duplicated code
bits that we have within THT.
Additionally this change adds a new shared value for ContainersCommon to
pull the required volumes for the docker_puppet_apply.sh script into a
single place. Unfortunately the existing volumes from ContainersCommon
includes a mount for /etc/puppet to /etc/puppet which causes problems
because we need to be able to write out a hiera value. The /etc/puppet
mount is needed for the bootstrap_host_exec function which is consumed
by various docker_config tasks but the mount conflicts with the puppet
apply logic being used.
Depends-On: I24e5e344b7f657ce5d42a7c7c45be7b5ed5e6445
Change-Id: Icf4a64ed76635e39bbb34c3a088c55e1f14fddca
Related-Bug: #1741345
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
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 deploying with -e environments/config-debug.yaml, which sets
ConfigDebug to true, it is expected that puppet is run with --debug
--verbose. This has happened for most of the puppet uses (via
LP#1722752), but we missed enabling it for the init_bundle under
docker/services.
While we're at it we also add '--color=false' to the puppet apply
command of the init_bundle containers as that is what we use in the
other puppet apply runs.
Closes-Bug: #1738764
Change-Id: If529b83a7342b3ad17d705517978539d1c6b949e
During minor update pcs cluster is stopped during step 1.
Then we search for pcs managed containers at step 2.
But since pcs cluster is stopped, 'docker ps' won't report stopped
containers.
This change adds '--all' option to show all the containers.
Change-Id: If38a4f7e25d4d1f4679d9684ad2c0db8475d679b
Closes-Bug: #1737548
When new module are added, we may miss the symlink in
/etc/puppet/modules. And for consistency as we mount the
/usr/share/openstack-puppet/modules directory it’s better to add it
to the modulepath.
Change-Id: I963aede41403ebbe3b9afb55a725b304a30a0cbb
Closes-Bug: #1736980
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
Adds update_tasks for the minor update workflow. These will be
collected into playbooks during an initial 'update init' heat
stack update and then invoked later by the operator as ansible
playbooks.
Current understanding/workflow:
Step=1: stop the cluster on the updated node
Step=2: Pull the latest image and retag the it pcmklatest
Step=3: yum upgrade happens on the host
Step=4: Restart the cluster on the node
Step=5: Verification: test pacemaker services are running.
https://etherpad.openstack.org/p/tripleo-pike-updates-upgrades
Related-Bug: 1715557
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
Co-Authored-By: Sofer Athlan-Guyot <sathlang@redhat.com>
Change-Id: I101e0f5d221045fbf94fb9dc11a2f30706843806
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
We need to tag the HA containers with a special tag so
that the RA definition never changes. We do this step in THT
as opposed to puppet because we need to guarantee
that all images are tagged on all nodes *before* step 2 where the bundle
gets created.
NB: Getting the image name without the tag will require some more
yaql work to get all the cases right. Right now this works only
if we enforce that the image has a ':tag' at the end of the name.
So far this is always the case. If things change we will need to
amend this code.
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
Co-Authored-By: Sofer Athlan-Guyot <sathlang@redhat.com>
Change-Id: I362e6cf26fba77d3f949b7d2fc4b35a3eab9087e
This service allows configuring and deploying manila-share
containers in a HA overcloud managed by pacemaker.
The containers are managed and run by pacemaker. Pacemaker runs the
standard Kolla image but overrides the initial command so that
it explicitely calls manila-share. This way, we shield ourselves
from any unexpected future change in Kolla.
This container needs to use the 'docker_config' section to invoke
puppet (as opposed to 'docker_puppet_tasks'), because due to the HA
composability each resource creation needs to happen on the bootstrap
node of that service and 'docker_puppet_tasks' will only run on the
controller/primary role.
Based on work done in fdb233e64e
Partial-Bug: #1668922
Change-Id: Ifa94c506db5eb667690a19d594115a93d2a790b2
Depends-On: I797eea2f7788f65411964ccb852b5707e916416f