DevStack剖析（四）文件分布&练习脚本

软件的布局

DevStack 通常在根目录下存放主要的脚本。

doc – 存放文档说明。 tools/build_docs.sh 用来生成HTML格式的DevStack脚本。可以运行 tox -edocs.来生成完整的文档。

exercises – 包含有测试的脚本用来检查功能是否正常并演示部分OpenStack功能。这些脚本知道如何退出或是跳过为启动的服务。

extras.d – 包含有stack.sh  unstack.sh 和 clean.sh.中的钩子对应的分发脚本。更多信息参见插件的说明文档。

files – 包含一些零散的用于配置和操作OpenStack的文件。有配置文件的模板和系统依赖关系的信息。这也是映像文件下载存放的地方。

lib – 包含有每个项目对应的子脚本。每个首层的项目(Keystone, Nova等)在这里都有一个对应的文件。另外还有一些系统服务于项目的插件。这些变量和功能也被用于相关联的项目，比如说Grenade，来管理DevStack安装

samples – 包含了未包含在DevStack repo里的一个本地文件的例子。

tests - DevStack 测试套件很分散，多数包含测试functions 和 functions-common中的某个容易出问题的功能。

tools – 包含一些独立的脚本。它们通常指向一些顶层的DevStack配置，但是也可以单独运行。还有些子目录来支持像XenServer这样的环境。

脚本

DevStack脚本通常在标识行调用env(1) :

#!/usr/bin/env bash

有时候脚本需要确定DevStack的安装目录。Sometimes the script needs to know the location of the install directory. TOP_DIR 应该一直指向这里，即使脚本可能被放在某个子目录里:

# Keep track of the current DevStack directory.

TOP_DIR=$(cd $(dirname "$0") && pwd)

很多脚本使用functions 文件中的共享功能。还有rc 文件 (stackrc andopenrc) 经常被用来设置用户环境：

# Keep track of the current DevStack directory.

TOP_DIR=$(cd $(dirname "$0") && pwd)

# Import common functions

source $TOP_DIR/functions

# Import configuration

source $TOP_DIR/openrc

stack.sh曾经是一个庞大的脚本，包含了整个流程。现在它被分解成一些lib目录下项目相关的子脚本（就像上面说到的那样）， 这样stack.sh更好维护，也更利于代码重用。

这些子脚本有一些固定的入口，部分只是占个地方。这些入口会被stack.sh按下列顺序调用：

install_XXXX

configure_XXXX

init_XXXX

start_XXXX

stop_XXXX

cleanup_XXXX

在 lib/templates 下面有模板文件用来生成新的服务的子脚本。在<>里面的注释是描述如何使用模板，使用时需要删掉。

为了显示依赖关系和在什么情况下项目的功能被调用，最上层的像is_service_enabled 这样的条件调用要在 stack.sh中完成。子脚本中可能有级联的条件，例如测试 keystone 在configure_swift()中被开启。

stackrc

stackrc是DevStack中的全局配置文件。它负责调用 local.conf (或是 localrc 如果它存在) 。

stackrc 里面的东西大致如下:

• 由stack.sh直接处理的所有项目软件库和分支。
• 可能被 local.conf引用的全局变量，例如 DEST, DATA_DIR
• 全局服务配置例如 ENABLED_SERVICES
• 被用于多个服务的变量，没有明确的所有者, 例如VOLUME_BACKING_FILE_SIZE(nova-compute, nova-volumes and cinder) or PUBLIC_NETWORK_NAME (nova-network and neutron)
• 因为依存的关系，无法在项目文件中进行声明的变量，例如，source项目文件的顺序是不能变的，但是早处理的文件需要后续文件中的变量，这种情况不多。

另外，在 stackrc 中声明变量在 local.conf 被source之前不能改 (格式 FOO=${FOO:-baz}); 如果它们可以改的话就会被放在 local.conf 里面了。

 

练习Exercises

Exercises目录下的脚本是用来：对OpenStack的部分功能进行基本的验证，说明OpenStack的命令行客户端是怎么用的。

除了上述说明之外，exercise 必须要遵从这里说明的结构。 swift.sh 可能是对此最清楚的例子。这些脚本在测试时由 exercise.sh 按顺序执行。

·         开始和结尾都是一个横幅状的信息，方便在海量的日志里定位相关信息。如果结尾的横幅没显示出来， 可以确定脚本在中间终端执行，应该是发生了错误。

echo "**************************************************"

echo "Begin DevStack Exercise: $0"

echo "**************************************************"

...

set +o xtrace

echo "**************************************************"

echo "End DevStack Exercise: $0"

echo "**************************************************"

·         scripts 通常会设定shell的 xtrace 属性，这样实际执行的命令行会显示出来。也设定 errexit 属性，遇到不为0的返回码时脚本会中断退出。:

# This script exits on an error so that errors don't compound and you see

# only the first error that occurred.

set -o errexit

# Print the commands being run so that we can see the command that triggers

# an error.  It is also useful for following allowing as the install occurs.

set -o xtrace

·         配置信息保存在 exerciserc, 一定要在 openrc 或 stackrc后被source：

# Import exercise configuration

source $TOP_DIR/exerciserc

·         在共享的子脚本中有几个提供帮助信息的功能，在检测到返回码不为0时会打印出一条信息并推出执行。大部分命令都会调用它们来检测：

swift post $CONTAINER

die_if_error "Failure creating container $CONTAINER"

FLOATING_IP=`euca-allocate-address | cut -f2`

die_if_not_set FLOATING_IP "Failure allocating floating IP"

·         如果你想跳过一个练习，比如说因为摸个服务没有启动，你可以用一个特别的返回码55退出练习，它会被确定为跳过。

·         练习脚本应该只使用几种 OpenStack客户端二进制程序与 OpenStack进行交互操作。特别是排除了任何 *-manage 工具，因为它们会直接访问配置与数据库，而练习本身也会直接访问数据库。

·         如果需要某个配置来让练习完成，它应该被放在stack.sh里，或是被 stack.sh 调用(参看 files/keystone_data.sh ，可作为一个例子f).

·         这些 OS_* 环境变量是唯一被OpenStack客户端用来作身份认证的。

• 执行成功后，练习必须要清理现场。如果没有运行成功，假定现场被保留下来了，可以让开发者进行后续的调试。如果再次执行，练习应该清理现场。重启主机甚至重新安装DevStack来确保有个干净的测试环境是可以接受的。