OpenStack单机Ubuntu虚拟机环境安装部署经验及源码结构简单介绍
OpenStack单机Ubuntu虚拟机环境安装部署经验及源码结构简单介绍(适合入门者) 。
本文主要关于近一个月对Openstack学习的一个总结，包括单机环境安装部署中出现的问题记录和源码学习的过程，适合入门者阅读。
一、openstack安装部署
目前看到的一个是官方的安装部署文档，一个是中文的OneStack脚本。
根据两个文档都能在虚拟机Ubuntu环境搭建好环境，中间也许或出现某些问题，搜一下应该可以得到解决。
因为OneStack的是中文的，在脚本每一句都有详细说明介绍，学习起来会轻松很多。
可以直接将脚本中IP修改为自己机器IP，运行脚本基本就能正常工作。
/etc/network/interfaces可改可不改，看具体情况，比如虚拟机使用的DHCP自动分配IP，会在一定时间后换一个IP才能访问网络，反正只要IP和配置对应上就OK。
一般虚拟机无法支持KVM的，所以这个地方记住得改VIRT_TYPE为qemu。
如果失败了又不知道原因，也可以自己一个一个模块根据脚本手动安装，找到原因就好解决掉。
比如从keystone开始安装，完了测试下是否正常，再依次安装glance和nova,dashbord。
如果搭建源码调试环境，可以git clone或者apt-get source获得源码，我使用的IDE是eclipse+pdev，以前用eclipse习惯
从源码安装可以使用pip install
如果还有遇到问题没解决的可以看下面的，也许是我遇到过的问题。
1.compute等服务阻塞导致无法正常启动
Nova-compute服务启动后阻塞在连接libvirtd，此时如果执行命令virsh list阻塞则执行命令killall -9 dmidecode再重新启动nova-compute即可
2.调试启动nova-*服务时将eventlet.monkey_patch()改为eventlet.monkey_patch(all=False,socket=True,select=True)，否则会出线程切换的一个错误吧
3.启动network服务时阻塞，log日志中在获取iptables则删除lock/nova中的文件重新启动
4.nova-volumes服务启动时如果出现卷XXX(如nova-volumes)不存在，则需要新建一个分区并创建volumes分配卷组名
pvcreate /dev/sda6
Can't open /dev/sda6 exclusively. Mounted filesystem?
出现以上错误的原因是分区文件正在使用中，必须先umount才行。
pvcreate /dev/sda6
Physical volume "/dev/sda6" successfully created
建好物理卷后可以用“pvdisplay”命令查看物理卷情况
pvdisplay
--- NEW Physical volume ---
PV Name /dev/sda6
VG Name
PV Size 1.06 GB
Allocatable NO
PE Size (KByte) 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID N2LgeT-RB4Y-8YEP-lO2J-tDWu-UeCT-4Obl8p
如果需要启动时挂载卷则修改/etc/fstab,按照规则增加一行该卷
创建逻辑卷组
vgcreate nova-volumes /dev/sda6
还有些问题一时不记得，先记到这，有问题再补充，下面简答介绍下几个模块的源码。
二、源码阅读
keystone，glance，nova结构都非常相似，使用wsgi协议,webob,paste,routes几个框架，像我这样以前Python没接触过的人可能也没接触过这些东西，先可以大致了解下这几个框架，再来看源码就大致知道怎么回事了。
先来说下keystone过程，下面是刚学习的时候记录的，直接贴过来，可能存在错误，有问题请指出，谢谢。
启动keystone服务时，需要查找keystone.conf配置文件并解析，通过keystone.conf配置的logging.conf解析logging日志配置。
deploy.appconfig会解析paste.deploy配置中 main section的部分
create_server中deploy.loadapp
一开始与appconfig一样，load app context。之后通过create方法解析paste配置的组成部分，并执行相关初始化。
use = egg:Paste#urlmap先得到解析执行，进入paste.urlmap#urlmap_factory，将先前loadContext得到的config map作为参数传入。
这里urlmap将会通过配置的uri和app对应起来，例如如果是composite:admin中的/2.0路径，将会继续通过查找每一个section pre找到pipeline中有一个pipeline:admin_api。
然后查找pipeline中最后一个应用的配置放入context.app_context，这里是admin_service。
Admin_service的协议是paste.app_factory，执行的方法是keystone.service:admin_app_factory。
再同样的方法查找所有filter放入context.filter_contexts.然后用这个pipeline context调用create方法，pipeline中则是先create app context再依次create filter context。
（从这里将从deploy模块回到keystone模块）Create app context执行admin_app_factory。
解析目录模版：
Catalog.RegionOne.identity.publicURL
Region=RegionOne
Service=identity
Key=publicURL
组合成json格式串
{‘RegionOne’:{‘identity’:{‘publicuRL’:’http://localhost:${public_port}s/v2.0’}}}
最终将整个目录模版解析成json格式的字典对象。
解析完成后得到一个带有adminURL目录信息的version_controller，
之后向routes.mapper添加路由信息，最终将构建完成的router返回给urlmap，完成请求路径与路由路径的一一对应。
路由对象保存了请求路径信息，controller信息，action信息。
至此,Keystone-all执行完成，启动了两个server等待请求，一个是admin_port等待，一个是public_port等待。
请求到达服务时，将会按照paste配置执行filters，然后根据路由表配置进入模块方法执行。
上面的介绍实际主要是讲paste和routes的过程，keystone利用这些框架，提供REST API，降低耦合，可以为各个模块提供用户认证功能。
下面简单介绍glance项目。
1.registry提供对DB操作的http服务，glance api通过对registry的http请求操作存储在DB中的镜像元数据，
虽然registry api可访问，一般用户不直接操作registry api
2.glance-api和glance-registry启动服务后，分别根据应用名和项目名查找paste配置文件，并部署路由信息
将镜像元数据放入HTTP请求头，并将镜像文件作为内容请求glance-api地址。
glance-api接收请求，解析以x-image-meta和x-image-meta-property-开头的请求头信息作为镜像元数据，
之后使用registry client请求registry服务，在DB中存储镜像元数据，并获取ID值作为镜像文件存储的文件名，
文件存储或者以其他方式存储完镜像文件后，再次请求registry服务更新镜像状态等元数据信息。