Files
d7c9d2e27e13c86859b1a3a7bc05e6f20d537568
devstack /unstack.sh

200 lines
4.1 KiB
Bash
Raw Normal View History

#!/bin/bash
# **unstack.sh**
# Stops that which is started by ``stack.sh`` (mostly)
# mysql and rabbit are left running as OpenStack code refreshes
# do not require them to be restarted.
#
# Stop all processes by setting ``UNSTACK_ALL`` or specifying ``-a``
# on the command line
UNSTACK_ALL=${UNSTACK_ALL:-""}
while getopts ":a" opt; do
case $opt in
a)
UNSTACK_ALL="-1"
;;
esac
done
# Keep track of the current DevStack directory.
TOP_DIR=$(cd $(dirname "0ドル") && pwd)
FILES=$TOP_DIR/files
# Import common functions
source $TOP_DIR/functions
# Import database library
source $TOP_DIR/lib/database
# Load local configuration
source $TOP_DIR/openrc
# Destination path for service data
DATA_DIR=${DATA_DIR:-${DEST}/data}
if [[ $EUID -eq 0 ]]; then
echo "You are running this script as root."
echo "It might work but you will have a better day running it as $STACK_USER"
exit 1
fi
# Configure Projects
# ==================
# Plugin Phase 0: override_defaults - allow plugins to override
# defaults before other services are run
run_phase override_defaults
# Import apache functions
source $TOP_DIR/lib/apache
# Import TLS functions
source $TOP_DIR/lib/tls
# Source project function libraries
source $TOP_DIR/lib/infra
source $TOP_DIR/lib/oslo
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
source $TOP_DIR/lib/heat
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
source $TOP_DIR/lib/neutron-legacy
source $TOP_DIR/lib/ldap
source $TOP_DIR/lib/dstat
source $TOP_DIR/lib/dlm
# 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
load_plugin_settings
# 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``
GetOSVersion
set -o xtrace
# Run extras
# ==========
# Phase: unstack
run_phase unstack
if [[ "$Q_USE_DEBUG_COMMAND" == "True" ]]; then
source $TOP_DIR/openrc
teardown_neutron_debug
fi
# Call service stop
if is_service_enabled heat; then
stop_heat
fi
if is_service_enabled nova; then
stop_nova
fi
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
if is_service_enabled placement; then
stop_placement
fi
if is_service_enabled glance; then
stop_glance
fi
if is_service_enabled keystone; then
stop_keystone
fi
# Swift runs daemons
if is_service_enabled s-proxy; then
stop_swift
cleanup_swift
fi
# Apache has the WSGI processes
if is_service_enabled horizon; then
stop_horizon
fi
# Kill TLS proxies and cleanup certificates
if is_service_enabled tls-proxy; then
stop_tls_proxy
cleanup_CA
fi
if [ "$USE_SSL" == "True" ]; then
cleanup_CA
fi
SCSI_PERSIST_DIR=$CINDER_STATE_PATH/volumes/*
# BUG: tgt likes to exit 1 on service stop if everything isn't
# perfect, we should clean up cinder stop paths.
# Get the iSCSI volumes
if is_service_enabled cinder; then
stop_cinder || /bin/true
cleanup_cinder || /bin/true
fi
if [[ -n "$UNSTACK_ALL" ]]; then
# Stop MySQL server
if is_service_enabled mysql; then
stop_service mysql
fi
if is_service_enabled postgresql; then
stop_service postgresql
fi
# Stop rabbitmq-server
if is_service_enabled rabbit; then
stop_service rabbitmq-server
fi
fi
if is_service_enabled neutron; then
stop_neutron
cleanup_neutron
fi
Use unique build dir for pip installs There is a bug in pip [1] where it will choose to install a package from an existing build-dir if it exists over the version actually requested. Thus if a prior component has installed a later version of the package, the unpacked code is already in /tmp/$USER-pip-build; it gets re-installed and manifests in a confusing error along the lines of --- Downloading/unpacking requests>=1.1,<1.2.3 (from -r /home/stack//python-cinderclient/requirements.txt (line 5)) Running setup.py egg_info for package requests Requested requests>=1.1,<1.2.3 (from -r /home/stack/python-cinderclient/requirements.txt (line 5)), but installing version 1.2.3 ... error: Installed distribution requests 1.2.3 conflicts with requirement requests>=1.1,<1.2.3 --- I believe pip 1.4 fixes this problem, but it should always be safe to specify a unique build-directory for pip installs to avoid picking up old versions. We also add a cleanup_tmp function for clearing out anything that stack.sh might leave around when un-stacking, and add a catch-all for the pip-build dir. [1] https://github.com/pypa/pip/issues/709 Change-Id: I7ce919cddfd6d6175ae67bd864f82e256ebc7090
2013年07月16日 13:36:34 +10:00
if is_service_enabled dstat; then
stop_dstat
fi
# Clean up the remainder of the screen processes
SCREEN=$(which screen)
if [[ -n "$SCREEN" ]]; then
SESSION=$(screen -ls | awk "/[0-9]+.${SCREEN_NAME}/"'{ print 1ドル }')
if [[ -n "$SESSION" ]]; then
screen -X -S $SESSION quit
fi
fi
# BUG: maybe it doesn't exist? We should isolate this further down.
# NOTE: Cinder automatically installs the lvm2 package, independently of the
# enabled backends. So if Cinder is enabled, we are sure lvm (lvremove,
# /etc/lvm/lvm.conf, etc.) is here.
if is_service_enabled cinder; then
clean_lvm_volume_group $DEFAULT_VOLUME_GROUP_NAME || /bin/true
clean_lvm_filter
fi