openstack-helm/tools/gate/tests/validate-umbrella-upgrade-no-side-effects.sh
Dustin Specker 078a496937 upgrading umbrella w/o changes has no app changes
If a Helm upgrade is performed on the OpenStack Umbrella chart using
the exact same configuration as the first release, then it's expected
for no DaemonSets, Deployments, or StatefulSets to be updated.
This did not work as expected.

A few changes were required to support this desired behavior:
1. Update glance's configmap-etc.yaml to trim whitespace and convert
   YAML comment to Helm template comment. Before this change, Helm
   rendered the template with the YAML comment and a newline for the
   install phase. On upgrades, Helm rendered the template without the
   YAML comment and newline causing the hash of configmap-etc to change,
   thus causing the glance-api Deployment to update.
2. Update openstack.sh script to create a randomly generated memcache
   secret for glance. Without this change, the glance-api deployment
   changes each time since Helm randomly generates a new memcache
   secret if not provided.

This behavior is enforced via a new test script,
validate-umbrella-upgrade-no-side-effects.sh.

The following jobs are always recreated due to hooks:
- keystone-bootstrap
- keystone-credential-setup
- keystone-db-init
- keystone-db-sync
- keystone-domain-manage
- keystone-fernet-setup
- keystone-rabbit-init
- rabbitmq-cluster-wait

Some Jobs are created via CronJobs and could be created during
validation. So far, heat-engine-cleaner has been seen, but others
could be caught too.

So the validation script ignores these pod changes by ignoring if
Jobs were recreated. Plus Jobs being recreated should not impact
the OpenStack deployment.

Change-Id: Iffaa346d814b8d0a3e2292849943219f70d50a23
2022-06-28 15:55:31 -05:00

45 lines
1.6 KiB
Bash
Executable File

#!/bin/bash
set -ex
# This test confirms that upgrading a OpenStack Umbrella Helm release using
# --reuse-values does not result in any unexpected pods from being recreated.
# Ideally, no pods would be created if the upgrade has no configuration change.
# Unfortunately, some jobs have hooks defined such that each Helm release deletes
# and recreates jobs. These jobs are ignored in this test.
# This test aims to validate no Deployment, DaemonSet, or StatefulSet pods are
# changed by verifying the Observed Generation remains the same.
# This test case is proven by:
# 1. getting the list of DaemonSets, Deployment, StatefulSets after an installation
# 2. performing a helm upgrade with --reuse-values
# 3. getting the list of DaemonSets, Deployment, StatefulSets after the upgrade
# 4. Verifying the list is empty since no applications should have changed
before_apps_list="$(mktemp)"
after_apps_list="$(mktemp)"
kubectl get daemonsets,deployments,statefulsets \
--namespace openstack \
--no-headers \
--output custom-columns=Kind:.kind,Name:.metadata.name,Generation:.status.observedGeneration \
> "$before_apps_list"
helm upgrade openstack ./openstack \
--namespace openstack \
--reuse-values \
--wait
kubectl get daemonsets,deployments,statefulsets \
--namespace openstack \
--no-headers \
--output custom-columns=Kind:.kind,Name:.metadata.name,Generation:.status.observedGeneration \
> "$after_apps_list"
# get list of apps that exist in after list, but not in before list
changed_apps="$(comm -13 "$before_apps_list" "$after_apps_list")"
if [ "x$changed_apps" != "x" ]; then
echo "Applications changed unexpectedly: $changed_apps"
exit 1
fi