使用devstack安装部署openstack

devstack虽然号称是最傻瓜的部署openstack方式，但是貌似只适合单机开发部署，也就是实验性质的，真正部署产品级别的openstack还是比较麻烦的。
devstack官网（http://devstack.org/）上就简单的两步：

1、git clone
git://github.com/openstack-dev/devstack.git

2、cd devstack; ./stack.sh

但devstack貌似如果安装的姿势不对，各种坑爹的bug。
首先讲一下我成功部署的环境：
win7 64 bit里开VMware虚拟机，安装Ubuntu 12.04 32 bit
Desktop。
如果Ubuntu是32bit的，那么运行stack.sh之前，需要修改stackrc Line 115-116中，两处的cirros-0.3.0-x86_64-uec都改成cirros-0.3.0-i386-uec，或者全局替换所有的也没关系。原因就是本文后面的“注意点 1”所讲的，让openstack加载的demo image是32bit的，而不是64bit的。若这个文件下载出错，也可以手动进入http://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-i386-uec.tar.gz，下载后的文件放在/opt/stack/devstack/files下面，再次运行stack.sh。
第一次运行stack.sh时，会指示输入一连串密码。以后再运行stack.sh，就不会要求输入密码了，因为第一次输入的密码已经被保存在localrc中了，再次运行时将默认使用该密码。（11.10里有bug，不会在home里的devstack下生成localrc，但是/opt/stack/devstack下还是会有localrc。）
openstack需要在stack用户下配置和运行，因此stack.sh运行一开始，就会给系统创建名为stack的用户。这个用户的主目录在/opt/stack/，而不是一般的/home/stack。以后如果要用命令行配置openstack，一般都要进入stack用户身份。
运行成功之后，如图显示：


可以用浏览器登录所指示的ip，如图中的10.214.24.146，默认用户名是admin和demo，密码是一开始自己设置的。所登录的管理界面是openstack的dashboard，是一个Django程序。


可以用已经存在的demo image创建一个虚拟机实例。创建后要稍等片刻，等到实例的状态显示“Active”后，才能通过VNC控制台进入虚拟机。貌似直接显示的VNC无法输入命令，需要点击上方蓝色提示框的“Click here to show only VNC”，之后才能正常输入用户名密码登录，如图：


用默认的用户名cirros、密码cubswin:)登录成功之后，就可以操控该虚拟机实例了：


部署的注意点：
1、上述环境中的stack.sh运行后会有一个bug，就是清除了DNS配置文件/etc/resolv.conf的内容，里面所有nameserver项都没有了，所以运行前可以先备份一下，或者运行后再修改，都是可以的。
2、VMware所在的环境（即这里的Win 7）应该关系不大，但是安装的Ubuntu是32bit还是64bit对后面使用openstack加载镜像时是很有关系的，因此最好慎重选择。
简单来说，就是如果openstack所在的操作系统环境是32bit的，那么就openstack里所虚拟的操作系统image就只能是32bit的，反之就只能是64bit的。
如图所示，在32bit的Ubuntu上运行的openstack如果试图部署64bit的image所生成的实例，在boot时会失败，并提示如下：


3、最新版devstack貌似在ubuntu 11.10上有bug。
部署失败的环境：我一开始是用
独立系统32bit Ubuntu 11.10 Desktop，git最新的devstack，
结果貌似最新版devstack还不太稳定，会出现奇怪的bug：stack.sh在部署好openstack组件组件之后，有一步是安装一个仅为6M的小image（stack.sh里叫做Install Images），用来做demo用的，但是在运行到
TOKEN=$(keystone token-get | grep ‘ id ‘ | get_field2)
这句时，TOKEN获得的内容为空，导致后面用glance创建三个image时所使用的TOKEN不正确，因此无法创建，stack.sh中断运行。不过虽然有这个BUG，但貌似openstack还是装好了，只是demo没有弄好。
4、运行stack.sh时，网络环境一定要好。
如果选的软件源速度太慢，或者网络环境本身太差（=_=比如ZJU曹光彪主楼的烂网，强烈建议用有线+30米以上VPN），运行stack.sh下载不到依赖软件时会终止运行。万一终止运行时，可以再重新跑一遍，反正已经下载和安装的依赖软件它不会重复搞的。如果重复多次还是遇到“无法获取”或者“校验码错误”的问题，那么建议更换更快的网络环境或软件源。
12.04的163的软件源貌似比较慢，我用ubuntu自动选择软件源的方式，测试出来貌似ZJU这里cn99的速度最快。
5、运行stack.sh失败后，重新运行前要先killall screen;  killall python