作者：张华 发表于：2014-11-09
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明
( http://blog.csdn.net/quqi99 )
今天想debug一下nova-compute进程， 用devstack迅速安装之后， kill掉nova-compute进程，然后修改nova/cmd/__init__.py文件的“eventlet.monkey_patch(os=False)”为“eventlet.monkey_patch(all=False, socket=True, select=True)", 最后在eclipse中启动nova pydev工程的nova-compute进程。运行devstack无外乎就是想快速的搭建一个debug环境去将精力集中到想要调试的代码， 但是经常性的devstack或其他不相干的组件喜欢拖一下后腿。总结一下：
1, 执行第一次‘nova boot‘命令可以启动一个虚机， 但执行第二次时直接在nova-schedule那里就ERROR了， 机器配置还行，资源肯定是够的。所以调试了一番， 问题找到了， 在nova.conf文件的default段添加配置"service_down_time = 7200", 搞定。那是因为debug时间长了， nova-compute进程没有及时向DB汇报它还活着的状态， 这样nova-schedule误认为没有合适的计算节点可供调度了。
2, 在eclipse里直接运行没问题， 但只要一debug要调用nova-conductor的方法时断点就hang在那里出不来了, 日志中时不时出现”MessagingTimeout: Timed out waiting for a reply to message“， 来点绝的， 直接修改nova.conf文件，添加：
[conductor]
use_local=true
如果计算节点宕机了，但没有在nova里将这个host disable掉，在 service_down_time and report_interval setting时间内nova-schedule会误认为这个host仍然是alive的，从而出问题了。 另外也可能是olso的bug, https://bugs.launchpad.net/oslo.messaging/+bug/1338732
或者去掉RetryFilter,
scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter
3, 我将代码从master分支降级到icehouse后运行devstack时迁移DB的脚本报错不是说缺这个就是缺那个， 删除那个高版本的pyc文件， 搞定。
find . -name "*.pyc" -exec rm -rf {} \;
4, 在我的印象中， 运行devstack时， glance是最喜欢抽风的组件， 没空去搭理它， 那就在stack.sh里直接注释掉upload_image那行，最后再手动添加镜像了。
wget http://cdn.download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img
glance image-create --name=cirros-64 --disk-format=qcow2 --container-format=bare --is-public=True --progress < cirros-0.3.2-x86_64-disk.img
5, 和os-queues-api-version相关的error, 那是因为现在marnoi更名为zaqar， 需用zaqarclient代替marconiclient, 所以： sudo pip uninstall python_marconiclient 。不然python-openstackclient会去扫描/usr/local/lib/python2.7/dist-packages目录下的所有openstack.cli.extension模块去试图加载，这样zaqarclient与marconiclient两个都加载了重复了。
PLUGIN_MODULES.extend(get_plugin_modules(
‘openstack.cli.extension‘,
))
它造成的后果就是安装keystone的create_keystone_accounts脚本时会报“argparse.ArgumentError: argument --os-queues-api-version: conflicting option string(s): --os-queues-api-version”从而造成数据库里没有初始数据，最终你看到的错误是：
/bak/openstack/devstack/functions-common:286:die
2014-12-23 01:38:17.229 | [ERROR] /bak/openstack/devstack/functions-common:1192 Keystone fail to get token
6, openstack-client与其他如python-neutronclient等库版本不一致的问题，可通过配置LIBS_FROM_GIT配置让python-neutronclient这些库统一走git将库安装到/usr/local/lib/python2.7/dist-packages/python_neutronclient-2.3.10.post2-py2.7.egg-info
running install_scripts， 而不是pypi
LIBS_FROM_GIT=python-neutronclient,neutron-vpnaas,neutron-fwaas,neutron-lbaas,python-keystoneclient,python-glanceclient,python-novaclient,python-cinderclient
就会造成有时候使用openstack-client命令时报如下错误 ：
+++ openstack project create admin --or-show -f value -c id
2014-12-23 01:44:30.542 | ERROR: openstackclient.shell Exception raised: python-neutronclient 2.3.9.40.g9ed73c0 is installed but python-neutronclient<3,>=2.3.6 is required by []
7, oslo的那些模块也是很容易出问题的, 确保用最新的代码即可。
for olso_pro in `pip freeze |grep oslo |awk -F ‘==‘ ‘{print $1}‘`; do
echo ‘upgrade ‘ $olso_pro
sudo pip uninstall -y $olso_pro
sudo pip install --upgrade $olso_pro
done
8, 有时候， sudo python setup.py install将data文件安装到了/var/lib/etc/neutron目录下，后面加--prefix=/ 可以将其它装到/etc/neutron目录下
9, 有时候将openstack源代码从一个机器拷到另一个机器上运行时，这一行出现错误一个如下的SSL方面的错误，需：rm -rf ../requirements/.venv/
env http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS=file:///bak/openstack/.wheelhouse /bak/openstack/requirements/.venv/bin/pip install -U pbr
10, 虚机不能ping主机。检查虚机的eth0是否以非internal方式加到了ovs网络里，且路由又配置在eth0上
sudo ovs-vsctl -- --may-exist add-port br-phy eth0 -- set interface eth0 type=internal
http://blog.csdn.net/quqi99/article/details/40949799