OpenStack 部署分布式应用的一个坑

之前基于 OpenStack 部署了一个云，运营下来一段时间下来还算正常，出现了各种问题也是意料之内，基本都很快搞定。

搞云计算的人嘛，就得懂得多一些、深一些不是：）

但有一天有个客户找上来反映了一个小问题，虽然最终解决掉，却引发了我的深思。

问题

客户的应用很简单，也是在我们的平台上申请了虚机，然后自己用 keepalived 为后面的某 db 业务提供 HA 保障。一切运行的都很正常，突然有一天，死活访问不通 db 了。

通过查看日志，发现故障发生前 keepalived 发生了切换，灾备节点被切换了。一开始怀疑是 keepalived 配置问题，检查后发现都正常，而且灾备节点确实也拿到地址了。我们搞运维的同学怀疑是网络问题，但底下排查了半天，也没找到原因，而且别的业务都跑的好好的。

分析和解决

出现问题肯定不会是莫名其妙的，我仔细回想了 VRRP 的原理和 Neutron 的实现。keepalived 基于 VRRP 来切换主从节点，被激活的节点会抢到配置的虚地址。然而，neutron 里面为了防止虚机作恶，会记录每个虚机启动时候分配的 IP 和 Mac，并用这个地址来过滤，避免出现篡改源地址的恶意流量。好了，那问题来了，neutron 并不知道某个虚地址其实是在两个 port 上都可能出现的，就会阻碍切换后的灾备节点流量通信。

问题定位到，就好解决了，直接改 iptables 规则，或者开启 Allowed-Address-Pairs (https://review.openstack.org/#/c/38230/) 即可。

进一步思考

从应用的角度看，VRRP 这种切换地址机制毫无问题；从 OpenStack 角度看，你申请一个虚机配置好了地址后，我只允许已知地址的流量出来，也是正常的。但偏偏两个结合到一起就有了问题。这根子上还是在于上层应用和底层平台之间的整合出现了偏差。其实系统就是这样，俩都正常的组件，放一起不出问题的概率很小，这也是为啥接口设计很关键。

我们一直说，要懂业务，要理解业务，其实也是避免设计出的产品跟真实的需求出现偏差。

首先，客户往往并不懂技术（甚至自己都不懂业务），这意味着他们很难用准确的语言描述清楚自己的真正需求（甚至自己都不知道真正需求是啥）。这就需要提供服务的团队要做到比客户更懂自己的业务，这是赢得客户信任的一个极大的优势。懂得从客户需求到业务流程到底下各种技术栈的灵活运用，这才是优秀的技术人员。

另外，就是产品的形态很重要，为什么现在云有 IaaS、PaaS、SaaS 等多种分类，其实这不同的产品形态都是针对不同的客户群体，满足不同的业务需求。呈现细节越少，意味着灵活性越差，但客户使用难度会降低。但无论是那种形态，都应该有严格的范围限制和操作保障，要让完全不懂技术的人能成功操作，甚至各种误操作也能纠正过来。在这点上，OpenStack 是做得很差的，这也是为什么基于 OpenStack 做云服务，首要任务是替换掉 Horizon。极简设计和极繁设计，无所谓高低，合适最好。

最后就是要选择合适的工具。现在开源特别发达，甚至同一个应用场景会出现数个优秀的开源产品，光看特性都是很吸引人。这个时候，选择就很重要了，最看重啥特性？二次开发的难度有多大？针对需求选这个是否合适？选择对了，事半功倍，反之往往陷入各种坑难以自拔。

OpenStack Summit 2015 Tokyo 有感

本次峰会是 10.27 ~ 10.30，四天在东京的品川站附近召开，6000 多人参会，几百个主会 speak 和各个项目的 design summit。

因为要做一个有关容器和网络的 speak，所以，虽经波折，最终还是按时参加了峰会。业余玩社区确实挑战比较大。

整体感受是，时间很紧，内容很多，身体压力很大。虽然只挑了最核心最热门的话题去听，也是从早到晚急匆匆地从一个会场赶到另一个（好几个 building）。一天下来，疲劳的很。

社区，不只是技术

开源项目的成功，除了技术外，往往还有很多很重要的因素。

比如怎么运营社区，怎么跟商业公司合作，怎么处理各个团队的关系……

毫无疑问，OpenStack 到今天能这么火，在各个方面做得都是非常优秀的。

本届大会，基本上越大的主题演讲 topic 都越浅显一些，但是人满为患；design summit 则集中到具体项目进行设计的讨论，反而人气没那么旺。

参加的人员，技术人员仍然是主体，但是非技术人员也不少见。

云，其实本质上不是个技术的事情。呵呵呵~

容器和网络是热点

OpenStack 社区对容器还是很积极的一个主动拥抱态度，各个项目都在考虑虚拟化对象是容器的新场景。

实际上，无论是 Docker 系列，K8s、Mesos，都有一些相对完整的 solution，无需 IaaS 的支持，自己就可以玩得很好。

但 OpenStack 社区还是希望底下用自己，所以努力提供新的 API 来支持这些 solution。

两边的定位有 overlap，肯定会冲突。底层平台必须要主动考虑上层 workload，考虑应用特性。这个是生产关系决定的。

网络话题这次被广泛关注，大会报告中有好几个都在谈网络（包括 SDN 和 NFV）。这次来参会的公司也有不少是网络公司，不过技术上新的东西不多。

比较搞笑的是，这次峰会的超级用户奖颁给了 NTT（sponser 了现场的网络接入），然而 wifi 接入体验比较一般（本来多好的宣传机会！）。

两个值得关注的项目，kuryr 还有 ovs 自己搞的 ovn 等开始亮相社区，都挺有意思，定位思路很清晰，不像 Magnum，做起来的问题不大。

围绕 neutron，问题不少，但是老框架在这里，能周旋的余地很少。怎么能跟别的项目更好的集成，怎么提供更好的性能，都是很现实的问题。

强调下，云计算的技术基础是计算虚拟化，然而成功能否，根本取决于网络。

到现在还没意识到这点的，基本可以歇了。

比较遗憾的是，有一些传统网络厂商，没能很好的抓住云计算这波机会。亡羊补牢，为时未晚，还可以考虑抓紧时间布局物联网。

技术周期趋向成熟

基本上，新的项目 focus 的 scope 都圈得比较小。

很多人开始关注实际的部署和运维方面的一些问题（再次强调下我的观点，云环境中，ops 将变得比 dev 更重要！）。

这很正常，最多的 80% 的需求也是最基本的，剩下 20% 不好做，不是通用需求，但往往是差异化和体现技术实力的点。

很多人会松了口气，趋向成熟，意味着再也不用跟着后面折腾太多升级了。

成熟后怎么能再健康的发展下去，是每一个成功社区都会碰到的问题，现在已经有点由盛转衰的意味，虽然不明显。

国内力量不可小觑

market place，国内公司（特别创业公司）见到不少。除了传统方案和硬件厂商，就是日本本地企业和国内企业，甚至国内企业感觉比日本企业还多一些。

而且来的人好多，一下子就是好几十号人，庞大的队伍！

做应用的企业没见到……，不过有一些很有特色的小企业，比如 cumulix 啊、puppet、solinea 啊，哈哈哈~

这次本地报告也不少，竟然还出现了用日语讲报告的情况。

各种基于 OpenStack 的方案，各种特点。

乐观看，大家都尽量兼容 OpenStack，又努力做出自己的特色；悲观看，差异化和成长空间可能有限。

日本的文化和生活

日本是一个很有意思的地方，学习了东方和西方的文化，糅合在一起，难免有不少纠结的地方。

也许是意识到这种文化的缺位，对于传下来的和服啊、武士道啊、艺伎表演啊，就都十分重视。

但日本文化上其实是封闭的，现在年青一代很少愿意去接触外面的世界。整个日本社会就像是一个精密的大机器，每个人按照职责努力的工作。七八点上班，十一二点下班，很少有跳槽，很少有变化，压力太大，森严的规矩，老龄化……日本的年轻人，不容易！

生活成本低、贫富差距不大，这些西方社会普遍的特色，也造成了日本现在已经进入了高度稳定甚至停滞期。

OpenStack 主要项目一览

OpenStack 发展十分迅速，目前已经包括了几十个正式项目，和大量的孵化项目，基本实现了 AWS 的大部分功能。

业务项目

基础架构层

计算服务

• Compute (Nova)：提供虚拟机形式的虚拟化
• Bare Metal (Ironic)：提供裸机形式的虚拟化

注：目前除了不完整的 Nova-Docker，还没有提供容器形式的虚拟化项目，Magnum 目前定位更多的是在上层。

存储服务

• Image service (Glance)：存虚拟机镜像
• Object Storage (Swift)：存对象
• Block Storage (Cinder)：块设备
• Shared Filesystems (Manila)：最初基于 Cinder 的共享文件系统。这个有单独存在的必要么？

网络服务

• Networking (Neutron)：十分完整的网络虚拟化功能，缺乏完善的安全服务，或许可以独立为新的项目。
• DNS (Designate)：DNS 服务

认证服务

• Identity (Keystone)：十分完整的认证、鉴权管理

编排

• Orchestration (Heat)：通过模板描述需要的基础资源组合，提供对其生命周期的高层管理接口。

其它

• Key management (Barbican)：加密数据管理
• Governance service (Congress)：Policy 管理

应用层

• Message service (Zaqar)：消息队列
• Database Service (Trove)：数据库
• Data processing (Sahara)：大数据处理
• Containers service (Magnum)：容器
• Application catalog (Murano)：应用目录
• Workflow service (Mistral)：工作流管理，任务之间的依赖，什么时间启动
• Key-value store as a Service (MagnetoDB)：键值数据库

支持项目

• Dashboard (Horizon)：web 界面。一贯的丑，但能用
• Telemetry (Ceilometer)：审计，统计，目前没有控制
• Common Libraries (Oslo)：基础库，这个应该是最有用的了，包括若干子库，config、context、messaging 等
• Deployment (TripleO)：部署一套 OpenStack 环境。实际上包括 RDO、DevStack 在内，都还不咋好用
• Command-line client (OpenStackClient)：对各个服务的 API 进一步封装为命令行客户端
• Benchmark service (Rally)：测试在大规模情况下的性能。这个估计各家会自己搞一套方案
• Puppet modules (PuppetOpenStack)：各种使用 puppet 相关的模块。puppet 和 chef 这种过度设计的工具，估计至少会消亡一个

转载请注明：http://blog.csdn.net/yeasy/article/details/46673265

OpenStack Magnum 项目简介

背景

Magnum 项目是 2014 年 11 月加入 OpenStack 的年轻项目，由 Rackspace主导发起，其定位是提供容器即服务（Container as a Service）的 API 框架，计划在 2015 年 10 月推出的 Liberty 版本时成熟。

我们知道，目前 OpenStack 中 Nova 项目已经通过 nova-docker 的形式支持了 Docker 容器（把容器当虚机管）。但在实际使用中，会发现有不少的问题。毕竟，Nova 设计的初衷是管理虚拟机，而容器跟虚拟机在行为和特性上存在较大的不同，无论是管理层还是底层的虚拟化支持层都完全不同。而且，让 Nova 支持各种各样的容器机制（Docker、OpenVZ、Rocket、LXC 等）要进行修改的地方着实不少，可能跟现有框架形成冲突。

此外，Heat 项目也支持 Docker 官方插件，来直接通过 Docker 的 REST API 来管理容器，并且支持容器的高级特性。然而，不支持资源的调度和网络功能。

社区之所以接收 Magnum 项目，一方面是容器技术现在着实火热，另一方面，也是往更高一层发展提供更好的支持。

设计原理

Magnum 在设计上，希望调用其它的容器管理平台的 API 来实现功能，自身作为一套 API 框架，目前支持 Docker、Kubernetes、Swarm 等。主要优势包括多租户、多后端框架、完善的容器功能、支持资源调度等。

如果说 Nova 是一套支持不同 Hypervisor （KVM、VMWare 等虚拟机平台）的 API 框架，那么 Magnum 则是支持不同容器机制的 API 框架。

基本概念

从小往大的顺序：

• Node：容器运行的节点，可以是裸机、虚拟机甚至容器。
• Bay：一组 Node 的集合（底层同一个驱动机制），是 Magnum 中容器调度的基本单元。Bay 在租户之间是隔离的。
• BayModle：类似于 Nova 中的 flavor，定义一个 Docker 集群的规格。

下面几个是来自 Kubernetes 中的概念。

• Container：容器。
• Pod：最小的管理单元，一个或多个相互关联的容器（一般运行相同应用），运行在同一个 Minion Node 上，共享同样的数据挂载和网络空间，代表某种应用的一个实例。
• Service：由一个或者多个 Pod 组成，代表一个抽象的应用服务，对外呈现为同一个访问接口，这样访问可以通过 service 来路由，而无需具体知道 Pods 的地址。
• ReplicationController：对 pod 指定副本数，RC 可以保证一直存在该数目的副本存在并运行。

主要服务

主要服务有两个，Magnum API 和 Magnum Conductor。

前者提供调用的接口，接收 python-magnumclient 的请求。可以同时运行一个或者多个实例。这些请求最终扔给 AMQP 消息队列，发送到 magnum-conductor 服务。

后者运行在控制节点上，具体负责将 client 的请求转发到具体的后端机制（Kubernetes API 或者 Docker API），目前限制只能存在一个实例。

DevStack 安装 OpenStack 多节点

目前安装 OpenStack 常见的方案有 Redhat 的 RDO 和社区的 DevStack。

当然，也可以手动安装，可以参考：github.com/ChaimaGhribi/OpenStack-Juno-Installation/blob/master/OpenStack-Juno-Installation.rst

其中，RDO 功能比较强大，运行也稳定，可以在一个节点上通过一个 answer 文件直接部署多个节点，搭建一套 OpenStack 环境。但是可惜，在 Ubuntu 上还不支持。

DevStack 支持 Ubuntu、Fedora 等环境，需要在每个节点上单独执行，适合进行实验。目前常见的教程一般都是讲解 DevStack 单节点安装。本文讲解最新的 Juno 版本在多节点上的安装过程。

网络环境

两台机器，分为控制节点（同时也作为网络节点）和计算节点。

控制节点

eth0: 9.186.100.77/24 作为管理网络（同时也是公共网络）。 eth1: 10.0.100.77/24 作为内部网络接口。

计算节点

eth0: 9.186.100.88/24 作为管理网络（同时也是公共网络）。 eth1: 10.0.100.88/24 作为内部网络接口。

配置 stack 用户

创建 stack 用户

sudo groupadd stack
sudo useradd -g stack -s /bin/bash -d /opt/stack -m stack

添加 stack 用户权限。

sudo echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

切换到 stack 用户

sudo su - stack

下载代码

下载 devstack 代码，并切换到 stable/juno 分支。

sudo apt-get install git -y 
git clone https://git.openstack.org/openstack-dev/devstack -b stable/juno

编写运行配置文件

在 devstack 根目录下，编写 local.conf。

控制节点的 local.conf

[[local|localrc]]

HOST_IP=9.186.100.77 # management network
PUBLIC_INTERFACE=eth0  #public network

FIXED_RANGE=10.0.100.0/24
#FIXED_NETWORK_SIZE=4096
FLOATING_RANGE=9.186.100.0/24
PUBLIC_NETWORK_GATEWAY=9.186.100.1

MULTI_HOST=1
LOGFILE=/opt/stack/logs/stack.sh.log

# Credentials
ADMIN_PASSWORD=admin
MYSQL_PASSWORD=secret
RABBIT_PASSWORD=secret
SERVICE_PASSWORD=secret
SERVICE_TOKEN=abcdefghijklmnopqrstuvwxyz

# enable neutron-ml2-vxlan
disable_service n-net
enable_service q-svc,q-agt,q-dhcp,q-l3,q-meta,q-metering,q-lbaas,neutron,tempest,heat

# OFFLINE=True

计算节点的 local.conf

[[local|localrc]]
HOST_IP=9.186.100.88 # management IP
FIXED_RANGE=10.0.100.0/24
#FIXED_NETWORK_SIZE=4096
FLOATING_RANGE=9.186.100.0/24

MULTI_HOST=1
LOGFILE=/opt/stack/logs/stack.sh.log

# Credentials
ADMIN_PASSWORD=admin
MYSQL_PASSWORD=secret
RABBIT_PASSWORD=secret
SERVICE_PASSWORD=secret
SERVICE_TOKEN=abcdefghijklmnopqrstuvwxyz

# Service information
SERVICE_HOST=9.186.100.77
MYSQL_HOST=9.186.100.77
RABBIT_HOST=9.186.100.77
GLANCE_HOSTPORT=9.186.100.77:9292
Q_HOST=9.186.100.77
KEYSTONE_AUTH_HOST=9.186.100.77
KEYSTONE_SERVICE_HOST=9.186.100.77

CEILOMETER_BACKEND=mongodb

DATABASE_TYPE=mysql
ENABLED_SERVICES=n-cpu,n-net,n-api,c-sch,c-api,c-vol

# vnc config
NOVA_VNC_ENABLED=True
NOVNCPROXY_URL="http://9.186.100.77:6080/vnc_auto.html"
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN

# OFFLINE=True

执行配置

执行命令。

./stack.sh

会输出各项操作的结果。日志会写到 stack.sh.log 文件。

其它事项

卸载 openstack

./unstack.sh

清除安装。

./clean.sh

有时候有些文件可能清除不干净，手动执行

sudo rm -rf /etc/libvirt/qemu/inst*
sudo virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh destroy

OpenStack 网络项目（Neutron）的历史、现状与未来

转载请注明：

http://yeasy.blogspot.com/2014/12/openstack-neutron.html

历史

OpenStack 作为最热门的云计算开源项目，自 2010 年 10 月发布第一个版本 Austin 以来，到 2014 年 10 月 发布 Juno 版本，已经经历了 10 个主要版本。基本稳定为每年 4 月和 10 月各发布一次大的版本更新。

网络功能实现是自第二个版本，即 Bexar 版本引入，最初作为 Nova 项目的一个功能 Nova-Network，仅支持所有用户共享一个底层网络（即所谓的 Flat 网络），后面自 2012 年 9 月发布的 Folsom 版本开始，将网络功能剥离出来，作为一个新的 Quantum 项目。2013 年 10 月发布的 Havana 版本中，项目改名为 Neutron。最新的 2014 年 10 月发布的 Juno 版本中，更引入了分布式路由（DVR）机制，并停止对于 Nova-Network 的支持。

各个关键版本的更新情况如下：

• Bexar 版本：
  • 引入 Nova-Network
• Cactus 版本：
  • IPv6 支持
• Diablo 版本：
  • FlatDHCP 网络下的 HA
• Essex 版本：
  • 网络功能数据模型开始从 Nova 中剥离，为独立项目做准备
• Folsom 版本：
  • 正式从 Nova 中剥离，成为新的独立项目 Quantum
  • 多租户隔离的支持
  • 插件式结构支持多种网络后端技术，包括 Open vSwitch、Cisco、Linux Bridge、Nicira NVP、Ryu、NEC
  • 支持 IP 地址的 Overlapping
  • 支持 provider networks
  • 支持基本的 L3 转发、SNAT、Floating IP
• Grizzly 版本：
  • 多网络节点支持，提高可靠性
  • 安全组
  • 支持 LBaaS
• Havana 版本：
  • 项目名称从 Quantum 改名为 Neutron
  • 多种物理网络（Linux Bridge，Hyper-V，OVS）类型同时支持
  • 引入 Fwaas、VPNaas
  • 引入 ML2 支持多种类型二层网络实现
• IceHouse 版本：
  • 一些新的插件
  • 新的 LBaaS 驱动
• Juno 版本：
  • 初步支持分布式路由（DVR）机制
  • 完整的 IPv6 支持
  • L3 agent 的 HA 支持
  • 一些新的厂商的功能插件

从上面的过程可以可以看出，网络功能从 Folsom 版本开始引进，经历了 Folsom、Grizzly、Havana、IceHouse 四个版本才形成了比较稳定的集中式网络模型。自最新的 Juno 版本开始，才开始采用分布式路由模型。

现状

作为云计算平台的基础之一，网络服务的实现无疑是最能体现技术实力之处。无论是功能全面与否、性能高低、稳定性，每一项想做到满足生产环境的众多要求，都不是那么容易的。这也是现在很多围绕 OpenStack 的创业公司立足之根本。

OpenStack 在宣传上，一直明确表明自身的网络是完全按照软件定义网络（SDN）的理念来设计的。实际上，即使是从网络已经正式成为独立项目的 Folsom 版本开始看，这种说法也是不准确的。这个不明确的设计理念也是目前 OpenStack 在网络项目上收到大量抱怨的重要原因之一。

我们知道，SDN 有几个特点，最基础的一点是以松耦合的方式来处理好控制平面与数据平面的关系。

OpenStack 在设计上的确做到了控制平面与数据平面的分离，所有的数据都存放在数据库，所有的 agent 监听来自 Neutron-Server 的消息，根据这些消息来执行本地的操作。从这个简单的模型上看，Neutron 确实采用了 SDN 的模型。

但是将控制平面与数据平面分离，这仅仅是漫漫长途的第一步。后面的如何设计数据平面，以及如何设计和实现控制平面，才是最为核心的地方。

目前，OpenStack 在这两点上是怎么实现的呢？

2009 年诞生的 OpenvSwitch 项目，提供了足够支持生产环境应用的虚拟交换机实现，可以无缝替换掉 Linux 自身的 bridge，并且还支持一系列额外的功能。看起来，这是个不错的项目。于是，在最初几个版本中，网络就同时支持了 Linux Bridge 和 OpenvSwitch。但是很可惜的是，从一开始，大家在使用 OpenvSwitch 的时候，仅仅是当作一个 Linux Bridge 替代品，在设计新的功能的时候，也局限于 Linux Bridge 所支持的功能。这导致理论上可以充当任意转发组件的 OpenvSwitch，在今天的 Neutron 项目中，大部分时候只是作为一个二层交换机在使用。

那么， 更为重要的控制平面呢？很遗憾，在这点 OpenStack 上的表现差强人意。虽不至于说存在技术漏洞，但至少控制平面缺乏统一的规划，以现代众多控制平面的实现角度去看，只能说是一堆功能放在了一起。为了解决一个部分功能，先用已有技术解决掉，而不管其它功能的实现。这也导致经常出现不同功能模块的冲突。分布式路由机制在 SDN 中是个很自然的事情，但现有的实现先后用了固定的地址映射、ARP 代理、多级的转发表、隧道、L2 Population……并不是说不能用这些技术，但是实现的复杂与紧耦合将给未来的扩展带来更多的困难。并且同时启用路由跟高可靠性、多类型服务链等等功能，现有的设计很难在不提高复杂度的前提下实现。

可能做网络研发出身的人比较难理解为何要这样设计。实际上，换个角度，从 Linux 系统自身管理的来看，这样的设计是有其合理之处的。在没有 SDN 的年代，用 Linux 自身做路由器或防火墙是很常见的事情，通过 IPtables、Linux Bridge 进行各种配置，总能满足局域网内的各种需求。然而，到了云时代，一台物理机动不动就上数十台虚拟机，甚至现在几百成千个的容器，同时是多租户的、有计费需求的、对安全可靠性需求很高的……这里面很多的场景，是之前简单应用 Linux 做服务器或网关时候所难以想象的。即使通过各种技术手段勉强解决了基本的需求，也只能造成今天这样复杂的局面。也可以想象，为何将网络接口接到交换机上这样的操作，在 OpenStack 里面是由 Nova 计算服务来负责的。

在这里也稍微感叹下，如果 OpenStack 当年没有 NASA 项目的代码基础、如果没有选择“生命苦短，我选 Python” 的 Python 语言开发，可能到今天的情况会更加不能让人满意。

当然，使用 OpenStack 除了上面的模式，还有另外一种用法：仅把 Neutron 作为一个框架，让后端的各种插件自己来实现各种网络的服务。这种情况下无疑对于现有代码的依赖最小，也无疑最为广大有自己成熟网络解决方案的厂商所推崇。但是这样的模式，肯定也不是社区能接受的情况。毕竟，仅作为一个壳子转发下各种调用，这失去了作为一个成熟云平台开源项目的意义。

未来

虽然指出了网络项目在设计上的诸多问题，笔者对于 OpenStack 仍然是推崇的。并非出于盲目喜爱开源项目的原因，更多的，自 Linux 项目后，这些年很难见到这么多业界巨头和开源届的紧密合作，一起进行一项解决实际需求的项目。

实际上，思考 Linux 项目之所以能成功的原因，很重要的一点，是 Linus 本人。并非只是因为他在操作系统内核方面的技术境界，不可缺少的一点是 Linus 本人是比较“偏执”的，他认定的事情就轻易不会改变。同时，在很长一段时间里 Linux 系统内核的维护只是由 Linus 说了算。这或许能给今天的 OpenStack 社区一些启发。OpenStack 已经成功了，再宣传赞助基金之巨、参与人数之多其实意义没那么大了。一个真正透彻理解云计算需求和技术的小团队，往往胜过大量自觉或不自觉站在各种立场上的参与者。

从目前的情况推测，在很长一段时间内，网络项目还将沿着现在的路子走下去，一方面是在分布式模型下的新的网络功能实现，以及解决与已有功能的冲突；另一方面仍然是各个厂商以插件的形式支持自己的网络方案。这两种方式发生冲突是迟早的事情，只是希望那个时候 OpenStack 中的网络已经选择了更为高效和可扩展的框架，可以真正地实现“任意替换”的软件定义网络。

附：OpenStack 发布历史（摘自官方 wiki）

Series  Status  Releases    Date
Kilo Under development Due Apr 30, 2015
Juno    Current stable release, security-supported  2014.2   Oct 16, 2014
Icehouse    Security-supported  2014.1   Apr 17, 2014
Havana  EOL 2013.2   Oct 17, 2013
Grizzly EOL 2013.1   Apr 4, 2013
Folsom  EOL 2012.2   Sep 27, 2012
Essex    EOL    2012.1   Apr 5, 2012
Diablo   EOL    2011.3   Sep 22, 2011
Cactus   Deprecated 2011.2   Apr 15, 2011
Bexar    Deprecated 2011.1   Feb 3, 2011
Austin   Deprecated 2010.1   Oct 21, 2010

OpenStack Heat 源码分析

目前还在进行中，开源在 https://github.com/yeasy/openstack_code_Heat，欢迎大家参与完善。

OpenStack节点地址改变

正常在生产环境中，各个节点会做HA，可以用域名机制来管理节点。

但是有时候如果用了IP地址，就面临着一旦改变了IP需要更新配置的问题。

如果要修改的话，主要是两个方面的信息。

一是配置文件，基本都在/etc/目录下。

可以先grep地址下看看是不是都可以直接替换，如果可以的话，执行

$ sed -i "s/old_ip/new_ip/g" `grep old_ip -rl /etc`即可。

另外一个是数据库，这个要略微复杂些。

一般openstack的数据库中有多个database，主要需要修改的在keystone database的endpoint表中。登录到sql后，命令如下

mysql>use keystone;

mysql> update endpoint set
    -> url=replace(url,'1.1.1.1','2.2.2.2');

其它的如token表中内容或其它database中内容，可以根据自己情况来看是否需要修改。

最后是重启所有的相关服务，或者干脆重启机器。

OpenStack Heat template中类型定义的一个坑

最新的Heat template目前支持string | number | json | comma_delimited_list | boolean等类型。


采用默认的hot格式，yaml文件格式。


定义一个string类型的属性，内容为true或false的时候，会报错。


查看heat engine的log会发现这个属性值默认被转为了boolean类型。


这是为何呢？
查看heat的代码，heat是调用的yaml库来直接load文件的，而对于yaml语言来说，如下的字符串都会被解析为bool类型。


y, Y, yes, Yes, YES
n, N, no, No, NO
true, True, TRUE
false, False, FALSE
on, On, ON
off, Off, OFF

OpenStack Heat中添加新资源示例

在OpenStack Heat中，资源都是通过继承resource类来实现的。
heat-engine在启动的时候会扫描预设目录来加载各种资源插件。
这种模式提供了极大的灵活性，用户可以很容易的添加自己的资源类型和指定响应行动。
下面给出了定义新资源的一个简单示例，资源被创建后在log中给出属性信息。

#This file should be put into the plugin_dirs of OpenStack HEAT.
#plugin_dirs=/usr/lib64/heat,/usr/lib/heat
#After that, restart the heat engine to enable it.
# service openstack-heat-engine restart

#Provide the OS::Neutron::ServicePolicy resource.

from heat.engine import attributes
from heat.engine import properties
from heat.engine import resource
from heat.openstack.common import log as logging


LOG = logging.getLogger(__name__)


classServicePolicy(resource.Resource):


    PROPERTIES = (
        NAME, SRC, DST,
    ) = (
        'name', 'src', 'dst',
    )


    ATTRIBUTES = (
        NAME,
    )


    properties_schema = {
        NAME: properties.Schema(
            properties.Schema.STRING,
            _('Name of the service policy.')
        ),
        SRC: properties.Schema(
            properties.Schema.STRING,
            _('Source of the service policy.')
        ),
        DST: properties.Schema(
            properties.Schema.STRING,
            _('Destination of the service policy.')
        ),
    }
    attributes_schema = {
        NAME: attributes.Schema(
            _('Name of the service policy.')
        ),
    }


    def handle_create(self):
        LOG.info(self.properties.get(self.NAME))
        LOG.info(self.properties.get(self.SRC))
        LOG.info(self.properties.get(self.DST))


    def handle_delete(self):
        pass


    def _resolve_attribute(self, name):
        if name == self.NAME:
            return self.properties.get(self.NAME)


def resource_mapping():
    return {
        'OS::Neutron::ServicePolicy':ServicePolicy,
    }