一、环境准备
1. 准备：
两台虚拟机，第一台（hostname:devstack）充当控制、网络、计算节点（allinone），第二台（hostname:devstack-com）充当计算节点。内存为8G、磁盘100G全部挂在/下，便于开发。安装Centos Linux release 7.2.1511，选择最简安装。OpenStack版本将对齐社区Master分支，目前即为开发中Queen版。
2. 网卡配置：
eth0 - 模拟业务网 - (192.168.0.0/24) ; eth1 - 模拟管理网 - (10.134.1.0/24) ; eth2 - 模拟外网 - (10.254.4.0/24)
devstack - eth0：192.168.0.156 、eth1：10.134.1.156 、eth2：10.254.4.156
devstack-com - eth0：192.168.0.157 、eth1：10.134.1.157
3. 整体规划如下：
二、自动化安装（step by step）
1. 配置国内base源：
[root@devstack ~]# cd /etc/yum.repos.d/ ; wget http://mirrors.163.com/.help/CentOS7-Base-163.repo
2. 安装git工具：
[root@devstack ~]# yum install git -y
3. clone源代码：
[root@devstack ~]# cd /home ; git clone https://github.com/openstack-dev/devstack.git
4. 创建stack用户：
[root@devstack /home]# /home/devstack/tools/create-stack-user.sh
5. 修改配置文件：
控制、网络、计算复用节点配置：
说明：HOST_IP为该节点的管理IP、密码均使用123456最简密码。
注： 此配置规划了将使用的外网网段，即FLOATING_RANGE、Q_FLOATING_ALLOCATION_POOL、PUBLIC_NETWORK_GATEWAY三个字段配置。若未规划，可将NEUTRON_CREATE_INITIAL_NETWORKS置为False，可以搭建完成后手动配置。
计算节点配置：
注：此配置中的PLACEMENT_SERVICE_HOST经测试为生效，由于目前Nova代码master版本缺少Placement配置会报异常，导致Nova-compute不能正常启动，即在安装出错后，得手动配置，在后面 （7.启动安装） 处会详细说明。
6. 更改文件用户：
[root@devstack ~]# chown -R stack:stack /home/devstack/
7. 启动安装：
控制、网络、计算复用节点（devstack节点）：
[root@devstack ~]# su stack
[stack@devstack devstack]$ cd /home/devstack/ ; ./stack.sh
到这里，devstack节点安装就完成了。区别于rdo的rpm包安装，devstack是源码安装。因为要install大量的python依赖，控制节点安装在2小时左右。
计算节点（devstack-com节点）：
[stack@devstack-com devstack]$ cd /home/devstack/ ; ./stack.sh
报错，发现n-cpu服务并未启动，可在/etc/nova/nova-cpu.conf中添加如下配置：
执行： [root@devstack-com ~]# systemctl restart devstack@n-cpu.service ， 即可完成安装。
8. 其余问题：
1）调整业务网：安装完发现，业务网走的还是管理网络，
options: {df_default="true", in_key=flow, local_ip="10.134.1.156", out_key=flow, remote_ip="10.134.1.157"}
但实际规划的是192.168.0.0/24网络做业务网，这里需要调整/etc/neutron/plugins/ml2/ml2_conf.ini文件：
重启服务：systemctl restart devstack@q-agt.service ，即可。
现在利用ovs-vsctl show命令可观察到：
options: {df_default="true", in_key=flow, local_ip="192.168.0.156", out_key=flow, remote_ip="192.168.0.157"}
2）手动创建网络：如果之前devstack节点的配置文件中， NEUTRON_CREATE_INITIAL_NETWORKS设为False，默认不会创建网络，要手动创建：
使用admin租户、admin用户： # source /home/devstack/openrc admin admin
创建外部网络： # neutron net-create ext-net --provider:network_type flat --provider:physical_network public --shared --router:external
创建外部子网：# neutron subnet-create ext-net 10.254.4.0/24 --name ext-subnet --allocation-pool start=10.254.4.205,end=10.254.4.215 --gateway 10.254.4.254
使用demo租户、demo用户： # source /home/devstack/openrc demo demo
创建租户网络：# neutron net-create demo-net
创建租户子网：# neutron subnet-create demo-net 192.168.1.0/24 --name demo-subnet --gateway 192.168.1.1
创建租户路由：# neutron router-create demo-router
子网接入路由：# neutron router-interface-add demo-router demo-subnet
子网设置网关：# neutron router-gateway-set demo-router ext-net
3） cell映射：
社区在O版后，nova引入了cellv2并强制使用，当新增计算节点后，要映射至所属cell中，执行
# nova-manage cell_v2 discover_hosts --verbose
9. 升级与重装：
1. 升级devstack代码：
# cd /home/devstack/ ; git pull
2. 升级组件代码（以nova为例）：
# cd /opt/stack/nova/ ; git pull
注意需要重启nova相关服务，db或者api_db有修改的话，需要把数据库拉至最新：
# nova-manage db sync
# nova-manage api_db sync
# systemctl restart devstack@n-api-meta devstack@n-api devstack@n-cauth devstack@n-cond-cell1 devstack@n-cpu devstack@n-novnc devstack@n-sch devstack@n-super-cond
3. 重装：
# cd /home/devstack/ ; ./unstack.sh 停止服务
# cd /home/devstack/ ; ./clean.sh 删除已有数据
# cd /home/devstack/ ; ./stack.sh 重新安装
4. 所有组件升级：
最好的方式就是重装，并建议删除/opt/stack下所有组件源码，重新clone安装依赖
三、环境确认、测试
1. 服务状态确认
Keystone: 服务内部没有mq通信，执行# openstack project list ， 有显示即正常。
Nova： 执行# nova service-list ， 查看各服务state是否为up。
Neutron： 执行# neutron agent-list ， 查看alive是否为:-)
Cinder：执行# openstack volume service list ，查看各服务state是否为up
Glance：服务内部没有mq通信，执行#glance image-list ， 有镜像显示即正常。
Horizon：本地登陆http://10.134.1.156/dashboard，若本地不通管理网，使用elinks http://10.134.1.156/dashboard 检查
2. 创建虚机测试
1. 使用demo租户、demo用户
# source /home/devstack/openrc demo demo
2. 创建本地虚机：
# nova boot test --flavor 1 --image cirros-0.3.4-x86_64-disk --nic net-id=89070a3f-1c28-480a-8db6-c59376b0ed07
3. 创建卷虚机：
# nova boot test-vol --flavor 1 --block-device source=image,id=58aa7836-eabb-431c-9247-5787680e6f46,dest=volume,size=1,bootindex=0,shutdown=remove --nic net-id=89070a3f-1c28-480a-8db6-c59376b0ed07
4. 查看虚机状态，直至active：
# nova list
5074d02d-8c4c-4d79-8997-5982f0517192 | test | ACTIVE | - | Running | demo-net=192.168.1.11
573961c6-354a-439a-a665-7058e3bc98bb | test-vol | ACTIVE | - | Running | demo-net=192.168.1.4
5. 登陆vnc进行进一步查看：
# nova get-vnc-console test novnc
novnc | http://10.134.1.156:6080/vnc_auto.html?token=23df2caf-095a-4c00-9933-5cefd0fb47d8
3. 网络状态确认
1. 外网连通信检测，最简单的方法就是，从本地去ping，netns中qrouter的qg口：
# ip netns exec qrouter-f8d0e07a-bc9f-4642-9892-9711b94c3410 ip a | grep 10.254
inet 10.254.4.210/24 brd 10.254.4.255 scope global qg-63090b03-08
# ping 10.254.4.210
2. 外网snat确认:
通过ns登陆虚拟机 # ip netns exec qdhcp-89070a3f-1c28-480a-8db6-c59376b0ed07 ssh cirros@192.168.1.4，若无法登陆，请放通安全组。
# ping 10.254.4.156
3. floatingip dnat确认：
创建floatingip：# neutron floatingip-create ext-net
绑定floatingip：# neutron floatingip-associate 3f9ecd27-e8c1-429e-a77a-d00af3c3bcaf 28e76da8-9fd6-4d55-b2c9-4b9c1b419c87
5074d02d-8c4c-4d79-8997-5982f0517192 | test | ACTIVE | - | Running | demo-net=192.168.1.11, 10.254.4.208
# ping 10.254.4.208
4. 迁移/热迁移确认：
1. hosts解析，stack用户需要互信，这些是devstack不会做的，自己手动配置下，具体方法就不说了
2. 登陆dashboard进行测试，观察resize后flavor的变化，live-migrate后host的变化，一般都是OK的
四、开发调试技巧
1. 查看安装服务
新版本的devstack用systemd取代了screen来启动服务
# systemctl | grep devstack
这里c-开头的就是cinder服务，g-开头的就是glance服务，keystone即keystone服务，n-即nova服务，q-即neutron服务，placement-api即nova-placement服务，dstat是以dstat命令为基础的监控，etcd是分布式存储服务、作为cinder的分布式锁。
所有守护进程服务都可以在/etc/systemd/system/下找到对应文件，即可找到入口及对应参数。
2. 查看日志
新版本devstack不再记录日志在/var/log 或 /opt/stack/log下，转而使用journalctl来代替：
# journalctl -a --unit devstack@n-cpu.service | grep XXX 这个相当于之前的 # cat /var/log/nova/nova-compute.log | grep XXX
# journalctl -f --unit devstack@n-cpu.service 这个相当于之前的 # tail -f /var/log/nova/nova-compute.log
3. 断点调试
由于目前devstack中很多服务都是依赖httpd启动的，传统的关闭守护服务，利用命令启动加pdb断点调试已不再试用，这里使用社区官方推荐的remote-pdb，即：
from remote_pdb import RemotePdb;RemotePdb('127.0.0.1', 4444).set_trace() 取代之前的 import pdb ; pdb.set_trace()
之后重启服务即可，调用对应api后进入断点，利用telnet或nc -t命令即可进行调试。
4. 综合分析、善用git
这里以nova为例，比如在Pike版本调度中，提出了基于Placement的Allocation candidates策略，即CPU、MEM、DISK过滤不再经过nova中的对应filter，而是发送rest请求给Placement服务，利用sql语句（不加以orm封装的）来直接过滤，得出候选主机。当然，Placement服务还在开发中，我们选择配置driver=caching_scheduler来屏蔽它，不过在目前（2017/12/20）的nova代码中，貌似行不通.......
1、问题复现：
修改nova.conf中的driver = filter_scheduler，改为driver = caching_scheduler，重启devstack@n-sch服务，再启动一个虚机，发现ERROR。
2、问题定位：
查看日志：# journalctl -a --unit devstack@n-sch.service | grep ERROR
发现：ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/manager.py", line 152, in select_destinations
ERROR oslo_messaging.rpc.server allocation_request_version, return_alternates)
ERROR oslo_messaging.rpc.server UnboundLocalError: local variable 'allocation_request_version' referenced before assignment
根据Traceback，定位问题发生在scheduler服务中，出错代码为/opt/stack/nova/nova/scheduler/manager.py第152行
3、阅读代码，进一步定位：
85 def select_destinations(self, ctxt, request_spec=None,
...................................
119 alloc_reqs_by_rp_uuid, provider_summaries = None, None
120 if self.driver.USES_ALLOCATION_CANDIDATES:
121 res = self.placement_client.get_allocation_candidates(resources)
122 if res is None:
123 # We have to handle the case that we failed to connect to the
124 # Placement service and the safe_connect decorator on
125 # get_allocation_candidates returns None.
126 alloc_reqs, provider_summaries, allocation_request_version = (
127 None, None, None)
128 else:
129 (alloc_reqs, provider_summaries,
130 allocation_request_version) = res
...................................
150 selections = self.driver.select_destinations(ctxt, spec_obj,
151 instance_uuids, alloc_reqs_by_rp_uuid, provider_summaries,
152 allocation_request_version, return_alternates)
发现只有当self.driver.USES_ALLOCATION_CANDIDATES为true时，才能得到allocation_request_version，否则该变量就不存在！！！
3、断点调试，确认问题：
在/opt/stack/nova/nova/scheduler/manager.py中插入断点：
119 alloc_reqs_by_rp_uuid, provider_summaries = None, None
120 from remote_pdb import RemotePdb;RemotePdb('127.0.0.1', 4444).set_trace()
121 if self.driver.USES_ALLOCATION_CANDIDATES:
安装remote-pdb ： # pip install remote-pdb ； 重启devstack@n-sch服务：systemctl restart devstack@n-sch；再次创建虚机
执行 # nc -t 127.0.0.1 4444 进入断点，进行简单调试：
发现caching_scheduler确实是不使用Allocation candidates策略的，引入allocation_request_version是引发这一问题的元凶。
4、利用git查找代码历史：
# git annotate /opt/stack/nova/nova/scheduler/manager.py
# git log
问题最终定位是引入这个patch，有兴趣的同学可以访问https://review.openstack.org/#/c/495854/，去看developer的讨论。
网友评论