Files
55f4dab4c640c6ed69d1796ecbafeef8e67fe7d7
devstack /clean.sh

149 lines
3.2 KiB
Bash
Raw Normal View History

#!/bin/bash
# **clean.sh**
# ``clean.sh`` does its best to eradicate traces of a Grenade
# run except for the following:
# - both base and target code repos are left alone
# - packages (system and pip) are left alone
# This means that all data files are removed. More??
# Keep track of the current devstack directory.
TOP_DIR=$(cd $(dirname "0ドル") && pwd)
# Import common functions
source $TOP_DIR/functions
FILES=$TOP_DIR/files
# Load local configuration
source $TOP_DIR/openrc
# Get the variables that are set in stack.sh
if [[ -r $TOP_DIR/.stackenv ]]; then
source $TOP_DIR/.stackenv
fi
# Determine what system we are running on. This provides ``os_VENDOR``,
Only use lsb_release for distro tags The existing GetOSVersion has a lot of unused code which is wrong in several ways - the only path tested in upstream CI is with lsb_release, because it's pre-installed on all nodes - the /etc/redhat-release checking probably still works, but is unnecessary - If using lsb_release, os_UPDATE has never actually been set. - the /etc/SuSE-release branch checking is broken if the lsb package is actually installed. lsb checking does not set os_UPDATE but yet the SuSE DISTRO setting relies on this to set a patch level (and so does some of the rpm tags). SuSE 11 is up to update 3, but the rpm matching is stuck hard-coded to update 2. I'm guessing installation is actually broken there. - the debian checking branch is broken. The VERSION tags have been removed and were not supposed to be relied on anyway (see notes in [1]) This simplifies things: - remove OSX checking (moved here after discussions in I31d0fdd30928ecc8d959a95838b1d3affd28ac6f) - only use the output of lsb_release. - A small best-effort check to pre-install lsb packages if not detected (that avoids chicken-egg-problem of package-install wrappers relying on os_* flags). - The unset os_UPDATE is removed. It's only previous use was for setting separate suse versions in the DISTRO element for matching during package installs (since removed) - DISTRO setting is modified to use the parts of os_RELEASE it wants. Per-above, this is the correct place to parse out specifics. - Call out the is_* functions, which are a better way to detect platforms - Export the variables as read-only, since they shouldn't be reset [1] http://sources.debian.net/src/base-files/7.5/debian/changelog/ Change-Id: I46a2c36d95327087085df07cb797eb91249a893c
2014年08月27日 16:15:32 +10:00
# ``os_RELEASE``, ``os_PACKAGE``, ``os_CODENAME``
# and ``DISTRO``
GetDistro
# Import apache functions
source $TOP_DIR/lib/apache
source $TOP_DIR/lib/ldap
# Import database library
source $TOP_DIR/lib/database
source $TOP_DIR/lib/rpc_backend
source $TOP_DIR/lib/tls
source $TOP_DIR/lib/libraries
source $TOP_DIR/lib/lvm
source $TOP_DIR/lib/horizon
source $TOP_DIR/lib/keystone
source $TOP_DIR/lib/glance
source $TOP_DIR/lib/nova
Add support for placement API to devstack Uses lib/placement, but relies on some functionality from lib/nova. This leads to some weirdness since the nova has special status in stack.sh. If/when placement is extracted it may be good to follow the devstack plugin structure instead. Because the placement code is currently a part of nova, there are dependencies in lib/placement on a some $NOVA_* variable and, if virtenv is being used, the virtualenv used by nova. Because placement currently runs using nova's configuration settings, not a lot actually happens in lib/placement: apache is configured and keystone accounts and endpoints are created. If PLACEMENT_DB_ENABLED is true then a separate placement db will be configured. When complete the initial version of the placement service will provide support for managing resource providers, inventories and allocations. The placement api only runs under mod-wsgi. Change-Id: I53dd3e6b41de17387a0e179fc9ac64c143b6a9eb
2016年07月12日 19:34:09 +00:00
source $TOP_DIR/lib/placement
source $TOP_DIR/lib/cinder
source $TOP_DIR/lib/swift
Begin new lib/neutron Background for this work can be read on the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2016-May/094063.html Usage of the new Neutron is by setting the following in ENABLED_SERVICES: * neutron-api * neutron-l3 * neutron-agent * neutron-dhcp * neutron-metadata-agent For now, the new neutron library supports just the ML2 plugin, with the Open vSwitch and Linux Bridge agents supported. All other Neutron plugins should be creating their own DevStack plugin if they wish for DevStack to support them. Many of them already do. Other notable changes compared to neutron-legacy: * Rely on the Neutron defaults, and force Neutron to make sane defaults instead of all kinds of knobs in DevStack. * Default to rootwrap daemon support * Use the security group driver by default * interface_driver can now use NEUTRON_AGENT (linuxbridge, openvswitch), since they are entrypoints in neutron's setup.cfg * Use NEUTRON_AGENT variable to determine which agent to run Works with NEUTRON_AGENT set to either "linuxbridge" or "openvswitch" Default is openvswitch for the time being. * Set ML2 configuration for VXLAN support * Remove Xen hypervisor stuff - it should be a plugin * Move L3 crud into separate service file: There's a lot of L3 configuration that was in the main neutron file, but a lot of it is self contained and can be moved into its own file. The new l3 service file will contain all the previous L3 plumbing and configuration that the OpenStack Gate expects, while also eventually moving the whole l3 network creation step into a single hook that can be overridden by plugins. * Introduce a check for a function "neutron_plugin_create_initial_networks" which will become the mechanism through which different topologies, and networking plugins can create and wire the initial networks that are created during a stack.sh run. The new lib/neutron is considered experimental, and followup patches will build upon this one. Existing users of lib/neutron-legacy should remain unharmed. Co-Authored-By: Hirofumi Ichihara <ichihara.hirofumi@lab.ntt.co.jp> Co-Authored-By: Dean Troyer <dtroyer@gmail.com> Change-Id: I31b6362c6d9992f425f2dedbbeff2568390a93da
2016年05月03日 09:03:09 -04:00
source $TOP_DIR/lib/neutron
set -o xtrace
# Extras Source
# --------------
# Phase: source
if [[ -d $TOP_DIR/extras.d ]]; then
for i in $TOP_DIR/extras.d/*.sh; do
[[ -r $i ]] && source $i source
done
fi
# Let unstack.sh do its thing first
$TOP_DIR/unstack.sh --all
# Run extras
# ==========
# Phase: clean
load_plugin_settings
run_phase clean
if [[ -d $TOP_DIR/extras.d ]]; then
for i in $TOP_DIR/extras.d/*.sh; do
[[ -r $i ]] && source $i clean
done
fi
# Clean projects
# BUG: cinder tgt doesn't exit cleanly if it's not running.
cleanup_cinder || /bin/true
cleanup_glance
cleanup_keystone
cleanup_nova
cleanup_placement
cleanup_neutron
cleanup_swift
cleanup_horizon
if is_service_enabled ldap; then
cleanup_ldap
fi
# Do the hypervisor cleanup until this can be moved back into lib/nova
if is_service_enabled nova && [[ -r $NOVA_PLUGINS/hypervisor-$VIRT_DRIVER ]]; then
cleanup_nova_hypervisor
fi
# Clean out /etc
sudo rm -rf /etc/keystone /etc/glance /etc/nova /etc/cinder /etc/swift /etc/neutron /etc/openstack/
# Clean out tgt
sudo rm -f /etc/tgt/conf.d/*
# Clean up the message queue
cleanup_rpc_backend
cleanup_database
# Clean out data and status
Async task support We have a *ton* of stuff in devstack that is very linear, specifically the ten-ish minutes we spend loading osc to run a single API command against something. We also generate configs, sync databases, and other things that use one core of our worker and make our runtime longer than it really needs to be. The idea in this patch is to make it super simple to run some things in the background and then wait for them to finish before proceeding to something that will require them to be done. This avoids the interleaving you would expect by redirecting the async tasks to a log file, and then cat'ing that log file synchronously during the wait operation. The per-task log file remains so it's easier to examine it in isolation. Multiple people have reported between 22-30% improvement in the time it takes to stack with this. More can be done, but what is here already makes a significant difference. Change-Id: I270a910b531641b023c13f75dfedca057a1f1031
2021年01月19日 12:10:52 -08:00
sudo rm -rf $DATA_DIR $DEST/status $DEST/async
# Clean out the log file and log directories
if [[ -n "$LOGFILE" ]] && [[ -f "$LOGFILE" ]]; then
sudo rm -f $LOGFILE
fi
if [[ -n "$LOGDIR" ]] && [[ -d "$LOGDIR" ]]; then
sudo rm -rf $LOGDIR
fi
# Clean out the systemd unit files.
sudo find $SYSTEMD_DIR -type f -name '*devstack@*service' -delete
# Make systemd aware of the deletion.
$SYSTEMCTL daemon-reload
systemd: Always create the systemd unit files Commit 5edae54 introduced the usage of systemd in Devstack. This allowed the transition away from 'screen'. Systemd needs "user unit files" to describe the services. Currently, those unit files get only created when an openstack service (n-cpu, c-sch, g-api, ...) is in the list of enabled services (`ENABLED_SERVICES`). This means, when Devstack is fully stacked, there is no way to start the systemd unit of an openstack service which is *not* in that list. This commit changes that behavior, and creates the systemd unit files independently of the list ENABLED_SERVICES. This means, when Devstack is fully stacked, I can start a systemd unit of an openstack service which wasn't in the ENABLED_SERVICES list. This allows more flexible lifecycle management of openstack services in the gate, which is useful for tests which test components which are not in the "default configuration" (e.g. the "nova-serialproxy" service). The `clean.sh` script purges all traces of systemd user unit files created by devstack. Change-Id: I0f7e1ee8723f4de47cbc56b727182f90a2b32bfb
2017年05月31日 11:21:22 +02:00
# Clean up venvs
DIRS_TO_CLEAN="$WHEELHOUSE${PROJECT_VENV[@]} .config/openstack"
rm -rf $DIRS_TO_CLEAN
# Clean up files
FILES_TO_CLEAN=".localrc.auto .localrc.password "
FILES_TO_CLEAN+="docs/files docs/html shocco/ "
FILES_TO_CLEAN+="stack-screenrc test*.conf* test.ini* "
remove clouds.yaml in clean.sh devstack failed to install because glance: Could not determine a suitable URL for the plugin patch I618ea8e27b49af360c905df85af06d9b1eef8407 tries to fix this problem, but with a wrong way because path is not correct, the clouds.yaml is not under /path/to/devstack/~/.config/openstack/ but ~/.config/openstack. patch I8af6bd465f74099c560dddba6b5221dd79cbc965 tries to fix this problem, but with a worng way to specify the path, ~$STACK_USER/.config/openstack/clouds.yaml will not expand with a variable, only const string can. $ whoami zqfan $ touch ~/.config/openstack/clouds.yaml $ export STACK_USER=zqfan $ rm -rf ~$STACK_USER/.config/openstack/clouds.yaml $ ls ~/.config/openstack/ clouds.yaml Change-Id: I549817d2f4638be615991c1726b39d270ba71357 ref: I618ea8e27b49af360c905df85af06d9b1eef8407
2016年04月12日 20:26:33 +08:00
FILES_TO_CLEAN+=".stackenv .prereqs"
for file in $FILES_TO_CLEAN; do
rm -rf $TOP_DIR/$file
done
remove clouds.yaml in clean.sh devstack failed to install because glance: Could not determine a suitable URL for the plugin patch I618ea8e27b49af360c905df85af06d9b1eef8407 tries to fix this problem, but with a wrong way because path is not correct, the clouds.yaml is not under /path/to/devstack/~/.config/openstack/ but ~/.config/openstack. patch I8af6bd465f74099c560dddba6b5221dd79cbc965 tries to fix this problem, but with a worng way to specify the path, ~$STACK_USER/.config/openstack/clouds.yaml will not expand with a variable, only const string can. $ whoami zqfan $ touch ~/.config/openstack/clouds.yaml $ export STACK_USER=zqfan $ rm -rf ~$STACK_USER/.config/openstack/clouds.yaml $ ls ~/.config/openstack/ clouds.yaml Change-Id: I549817d2f4638be615991c1726b39d270ba71357 ref: I618ea8e27b49af360c905df85af06d9b1eef8407
2016年04月12日 20:26:33 +08:00
rm -rf ~/.config/openstack
# Clear any fstab entries made
sudo sed -i '/.*comment=devstack-.*/ d' /etc/fstab