写出这么大个题目来，把自己都吓到了…然后赶紧在后面补了个（一），以示我的分析仍然很粗浅
建议想看源码的童鞋先看下这个视频，这也是目前来讲除了官方文档之外为数不多的资料了
应该说我跟他的理解比较接近，但是有出入…见仁见智吧
言归正传
我下载的版本是nova 2011.3 Diablo，也即2011年的最后一个稳定版。下载解压完毕后得到一个名为“nova-2011.3”的文件夹，下文约定以这个文件夹为根目录“/”
（1）
整个项目的入口应该是从/setup.py开始的，这个文件在设置了各种环境变量、语言翻译之后调用了setup()这个函数进行安装。安装的过程也大概就是把目录里的文件该放哪放哪，细节我木有仔细看…因为当初的主要目标也是要理个框架出来，以后要做那块的开发可以详细看
下面应该注意的是/bin这个文件夹。里面是nova各个服务的启动程序和给管理员的命令行程序。其实它们也都是python脚本，可以直接打开
简单看两个启动脚本先：
# from /bin/nova-api
for api in flags.FLAGS.enabled_apis:
servers.append(service.WSGIService(api))
service.serve(*servers)
service.wait()
和
# from /bin/nova-compute
server = service.Service.create(binary='nova-compute')
service.serve(server)
service.wait()
可以看到nova里面有两种service类型(service的定义在/nova/service.py)，WSGI service和普通service
按照我的理解，前者是对外提供ReSTful API的，后者是对内提供RPC调用的
显然service是要一直在后台跑的，所以最后service.wait()一直等待直到结束
然后看给管理员的命令行程序之一，/bin/nova-manage
这个程序的大致流程是，先对用户命令进行解析分类，确定相应的响应类，然后RPC调用具体的服务处理
文件里有个叫做“CATEGORIES”的列表，表示的是从用户命令到响应class之间的对应关系
（2）
至此，整个项目的大致流程就理清楚了，下面看一些我觉得重要的基础组件
第一个是flags这个模块。这个模块基于python-gflags这个项目，用来处理可由用户定义的各个参数，包括配置文件和通过命令行传入的参数。它的神奇之处是支持分布式的参数定义，即每个参数仅当需要处理的时候才会被定义，并且通过“import”互相联系起来
比如/nova/service.py里的这几个参数定义：
flags.DEFINE_string('ec2_listen', "0.0.0.0",
'IP address for EC2 API to listen')
flags.DEFINE_integer('ec2_listen_port', 8773, 'port for ec2 api to listen')
flags.DEFINE_string('osapi_listen', "0.0.0.0",
'IP address for OpenStack API to listen')
flags.DEFINE_integer('osapi_listen_port', 8774, 'port for os api to listen')
括号里面按顺序是参数名称，默认值和简短说明
另一个是rpc这个模块。这个模块默认调用kombu处理AMPQ，也就是经常在nova文档里面出现的RabbitMQ。
（3）
下面是我眼里openstack的结构
最下面是最基础的flags、database、rpc之类的模块，然后上面是nova-***这些服务，对外提供nova-api，服务用户
另外提供一个幻灯片，上周小组讨论时候的
