更新历史：
2018.02.07 初稿完成
2018.03.12 更新对 kuryr 现状的理解
前言
突然关注 Kuryr 是因为我正好在研究 k8s 集群如何跟 openstack 环境通信，我的 qinling 项目也有容器跟虚拟机的通信需求。k8s 现在是热门不假，但毕竟我们还在做 openstack 的生意，自然就会碰到虚拟机和容器的混合部署。直接在 openstack 集群部署 k8s 不现实，那样会对资源管理和运维带来很大不便。所以最直观的部署方式就是 k8s 和 openstack 是相互独立的集群，各自管理各自的资源，当然，更高级一点就是 k8s 跑在 openstack 的 vm 里，彼此是上下层的关系，利用
继续阅读 »
本文原本是在我的CSDN博客里发布，时隔几个月，重新温习一下，顺手完善一些内容，发在这里。（深藏功与名）
版本：Havana
部署：多节点
网络类型：vlan
之前的一篇blog中碰到了虚拟机访问169.254.169.254的问题，在F版中，会在网络节点上做NAT转换，直接访问nova的metadata服务，但这种方法，在使用namespace时就不生效了，因为namespace支持IP地址重叠，这样nova就无法区分到底是哪个虚拟机请求metadata。
该问题在G版得到解决，blueprint在此。采取的方法是在HTTP头部识别是哪个虚拟机。同时，G版在neutron中加入了两个服务：namespace me
继续阅读 »
测试目的
因为 catalyst cloud 马上要部署 magnum 服务，但 magnum 服务默认的网络插件是 flannel，但 flannel 目前仍不支持 network policy，这对于 production 上的客户来说有些不能接受，于是我们想给 magnum 增加 calico 的支持，但首先需要确认，用了 calico，pod 的网络性能不能太差。为了测试 pod 之间的带宽，于是才有了本篇博客，记录流程。
继续阅读 »
其实关于oslo.config的使用，在它代码库的oslo.config.cfg.py文件中有很详细的注释说明。但为了避免每次都去阅读一遍(而且有的用法确实不经常用)，还是有选择的做一下笔记，以便查询使用。这个笔记不是关于oslo.config方法的全集，因为有些东西我认为没必要记录的就略去了。
因为oslo.config用了iniparser和argparse，所以最好是对它们有一些理解和掌握。
术语：
本篇对于英文中的options统一翻译成配置项
配置项支持的类型
strings, integers, floats, booleans, lists,
'multi strings' and 'key/value p
继续阅读 »
写在前面
工作压力越来越大，每天疲于奔命，尽力的证明自己，但无奈个人力量太过单薄，才疏学浅，每天抱着改变世界的心投入工作，挣扎一天之后，看看周围还是云淡风轻，花开花落，于是又抱着明天继续改变的心，在回忆、梳理中慢慢入睡……
我没有目标，或者我认为我的目标就是做好当下，未来太遥远，看不清，也懒得看。过来人跟我说，往那边走吧，我略作迟疑，心想，他娘的反正我也不知道该走哪，一路都这么趟过来了，继续趟吧，走哪是哪，只要是路。人生就是这样，你可以后悔，但永远不能重新来过。
眼前有一个大水池，我打开进水口，在岸边盯着，看着水位慢慢上涨，心里突然有种莫名的欣喜。突然有一天我发现水位停滞了，甚至下降了，我开始惶恐。此时才发现，池的另一边，有
继续阅读 »
This blog was sent to openstack-discuss mailing list originaly.
As the official Victoria release is approaching and it has been a long time
silence for Trove in the upstream, I think it's good time for me as the Trove
PTL for the last 3 dev cycles to have a project update. The things that will be
described below have
继续阅读 »
今天已经是到波恩的第二天了，跟昨天晚上一样，回到住处后，先打开自己的电脑看个dota视频，因为听着09解说的声音，恍惚间感觉自己还在家里，恍惚间还能隐约听到媳妇说：别看了，讨厌很。因为生物钟的原因，今天早上4点多就醒了一次，强迫自己接着睡，不幸7点钟又醒了，索性爬起来，打开电脑看看微博。我的微博上领域性比较强，收听的人都是跟工作相关的，因为5号到8号是OpenStack香港峰会，所以微博上关于峰会的就比较多，但最引人关注的还是我司成功加入OpenStack金牌会员，我想这是华为迈向OpenStack的重要一步，否则一年50W美金的会费算是白瞎了。
继续阅读 »
写在前面：
因为目前的时间和精力都有限，每天团队里有很多杂事需要处理，博客更新的速度明显慢了许多。好在公司为我们提供了宽松、自由的办公环境，访问外网更加方便，并且因为跟内网隔离，也因此少了不少打扰。记得我在之前的博客中有提到，我不知道我还能坚持多久，但我会尽力。一方面是我促使自己不断学习的过程，另一方面，也希望能给初学者一些帮助，高手，尽量绕行吧，我不敢班门弄斧，但如果能提供一些建议和指正，定当感激不尽！OpenStack目前的形式仍然是如火如荼，各种新的组件，各种培训，各种交流，各种教程，大家的技能水平都有了明显提升，我的教程，也许受众会越来越少，呵呵，这是好事，当大家都是高手的时候，也许交流会更加高效。另外，那些加我QQ或微
继续阅读 »
更新历史：
2017.10.06，更新一些命令
OpenStack 大多数项目中都依赖消息队列（默认是 RabbitMQ ）在服务内部传递消息，同时，大多数关键项目（Nova、Cinder、Glance 等）也会将用户操作资源的动作以及资源的状态变化这些信息发送到消息队列，这些消息被称为 notification。任何对 notification 感兴趣的服务或组件都可以在消息队列上监听特定的 topic（默认是‘notifications’），从而获取这些 notification 并进行处理。OpenStack 官方推荐的获取 notification 的角色是 Ceilometer，其子项目 Panko 实现了对 notif
继续阅读 »