目前OpenStack项目里，目前我看到的最成功的项目，在最近2年里，应该就是kolla。我有幸在过去的1年半里参加了整个社区的开发过程。
Docker是一个革命性的东西。kolla作为一个用Dcoker来部署OpenStack的工具，其实也把其他的部署工具的命给革了。
Kolla介绍
Kolla，就是把OpenStack放到Docker里，部署OpenStack的一个工具。这其实也是目前为止，唯一一个没有厂商背景的部署工具
- 红帽的Tripleo，RDO，使用puppet，部署在CentOS 红帽系列
- Ubuntu的Juju，使用自己的配置管理工具，Juju，go语言开发，部署Ubuntu系统，
- Suse的Crowbar，使用Chef来部署，Suse企业版本
- Rackspace的OpenStack-ansible，通过LXC或者部署到物理机器上，利用ansible来管理，目前支持Ubuntu和CentOS
- Mirantis的Fuel，利用puppet，部署到Ubuntu操作系统上
- HPE的helion，使用ansible，部署在Debian 8
- TCPCloud搞的Salt，部署OpenStack。我没玩过，我的理解应该是在Ubuntu的系统上。
上面七个工具，基本可以囊括所有的OpenStack部署项目，每个都要他的好处，也是有他的不足的。他们的一个共同特点，基本都是单一厂商主导。
2017年，算是Kolla发展最猛的一年，一个没有厂商主导的部署工具，目前已经具备投入到生产使用。Kolla目前支持的操作系统
- CentOS和红帽系列
- Ubuntu16.04
- Oracle linux
我们自己也给客户做过很变态的测试，在Suse的企业版本上，跑一个CentOS的Docker镜像的OpenStack，完全没任何压力，并且还是多节点。
Kolla解决了一个困惑OpenStack长期的问题，升级，upgrade。通过Docker，可以很优雅的解决到OpenStack的升级的问题，现在已经可以实现业务跑着，进行升级。
这次OpenStack China Day，用kolla演示升级和集群掉电后，自动修复。把OpenStack做到可以让用户自己升级，这背后的故事，其实真的不少。
很多朋友对Docker不熟悉，以为把OpenStack放到Docker里，虚拟机也是跑在Docker里。其实这是误解。Kolla仅仅是吧OpenStack各个服务的进程，放到Docker里而已。以前的vm怎么运行，现在还是怎么运行，没做任何的改变。
Steven Dake
2014年，大概是下半年的时候，OpenStack基金会，已经意识到Docker对OpenStack可能造成的威胁，那么这个时候，就组成了一个小team，研究OpenStack和Docker如何并存，其实也都很容易想到，在2105年温哥华峰会上，推出3个项目
- Kolla，把OpenStack放到容器里，部署OpenStack
- Magnum，在OpenStack上面部署容器，后来改成COE（k8s，swarm，等）
- Solum，利用Docker来实现CI CD
这就当初基金会的设想，经过了2年的发展，大家其实已经发现，目前就kolla项目是最靠谱的。Magnum修改了自己的方向，并且带来的价值不大，仅仅是部署K8s。Solum，已经快要死掉。
Steven Dake，是以前的Heat的PTL，前红帽的工程师，评论技术多高已经没啥意义，这位哥们最厉害的地方，就是情商特高，能带动一堆人一起干活，我底下的弟兄，对他的也是赞口不绝，跟他干活，是一种享受，不拼命干好，对不起他的培养。
当时Steven Dake面临一个选择，是搞Kolla还是Magnum，那么他最终选择的Kolla，全力以赴搞好这个项目。
Kolla项目的活跃度，可以说在过去两年里，OpenStack各个项目排名，应该是在前五名以内。也是目前我看到，在过去两年里，唯一一个算是活跃的新项目。
目前Steven Dake还是基金会独立董事。https://sdake.io/ 他的blog
把OpenStack放到容器里，其实当时面临的技术挑战是很多的，没有我在外面吹的那么轻松。现在Docker的很多分享，还在讨论数据库是否放在容器里，容器的日志如何收集。对于Kolla来说，要做到100%容器化，他要付出的代价就更大，Qemu，Libvirt容器化，OVS容器化，这些都是没人玩过的。
Ansible
把OpenStack放到Docker里，那么用什么进行编排呢？这个决策，其实是PTL决定。k8s是否可行呢？
One thing we tried early on with Kolla was deploying OpenStack on top of Kubernetes 0.9.7;
Steven Dake在blog里提到，其实在k8s 0.9.7 的版本，就开始验证是否可行。如果当初kolla选择k8s作为编排引擎，作为重点开发，那么其实今天能做到什么程度，是非常不好预测。
为啥选择Ansible，当时其实红帽也没收购Ansible。那么一个八卦新闻就是：Steven Dake的太太是Ansible公司的。
从我看来如果不是选择ansible作为默认的编排引擎进行开发，kolla-ansible是不可能在短短1年内投入生产环境，Kolla真正可用放到生产的环境，是Mitaka版本。
经过了1年的完善，目前的Ocata版本，已经基本到了一个很完善的地步的。
Sam Yaple
Sam是Rackspace的员工，2015年，当时OpenStack各家公司社区贡献的环境，还是很宽松的时候，Sam参与的Kolla的开发，他一个人出活量，基本相当于其他人的总和。而且都是技术难点的活。
Neutron容器化，OVS容器化，libvirt，qemu容器化。都是他一个人完成的。而且是在一个周期L版本完成的。
而且Sam写的代码，你基本也发现不了bug。Sam已经在Mitaka版本发布后，退出kolla的社区。不过到现在为止，他的代码提交量，还是第一。
https://github.com/openstack/kolla-ansible/graphs/contributors
kolla今天能做到这个地步，Sam应该算是第二功臣。
Jeffrey Zhang
对于kolla来说，
- Steven Dake，规划了Kolla的技术方向
- Sam Yaple 解决了关键的技术难题
- Jeffrey Zhang，就是把Kolla推到生产中。
由于kolla是没有厂商主导的部署工具，那么他部署出来的环境，是否能满足生产需求，这是很多用户问的问题。这个问题靠拍胸口是没啥意义，还是要靠验证。
全球第一个Kolla的生产部署案例，出自Jeffrey Zhang, 53个节点，超过500个OSD的环境。Mitaka版本的Kolla，遇到的bug，都是Jeffrey Zhang一个一个去修复。
经过了1年的验证，Ocata版本的一个生产环境，在每个节点超过20个vm，压力负载很重的情况下，运行良好。期间我们已经把各种的问题，bug都修复。
http://stackalytics.com/?module=kolla-group&release=all&metric=resolved-bugs
不少于10个非常严重的bug，严重影响到生产运行的问题，都是Jeffrey Zhang同学修复的。
运气
kolla的运气，有时候好的令人难以置信。
- Steven Dake，选择了Kolla，选择了ansible.
- 2015年11月份，我选择了kolla，找到了Jeffrey Zhang一起玩
- 2016年2月，Docker发布了1.10版本，支持 mount propagation。解决了Kolla投入生产的关键技术问题。Neutron的各个服务，可以在单独的容器里。
- 2016年4月份，全球的第一个Kolla生产环境的客户，小白鼠产生，验证的Kolla的稳定性和可靠性。
- 2016年8月份，Intel给了130台机器进行kolla的规模测试。
- Ocata版本发布时间更改，从以前的4月份，改成2月份，就让kolla很多在Newton版本没完成的工作，可以在Ocata版本完成.
- Ocata版本，九州云加大Kolla的投入，根据公司产品的需求，不断完善Kolla。最后在OpenStack的5月份峰会前推出kolla的产品。
- 2017年五月份，一个OpenStack的深度使用用户，部署了kolla的Ocata版本，对Kolla的各种功能进行的检验。
- OpenStack China Day大会，演示Kolla的用户无感知升级，和群集掉电重启的功能。吸引了大量的眼球。这是在1年前还是无法实现的。
我的Team
这是一个最强的Kolla team。经常有朋友问我团队多少人。其实不多。
必须强调，我是一行代码都不会写的。都是弟兄的努力。
