Cisco Network Service Orchestrator是Tail-f网络控制系统（NCS）的演进。 Tail-f于2014年被思科收购。该产品已得到增强，并构成了思科NSO的基础。
今天遇到了一个非常奇怪的问题：在root用户下，python的sys path中包含了/usr/local路径下的site-packages目录，但是在非root用户下，却没有包含，导致该用户执行程序异常，报：ModuleNotFoundError。
最近大半年一直在参与公司针对OpenStack的一些定制开发，主要是与Neutron组件相关。大大小小的各个项目中，与华为、中兴、EasyStack等都有过合作，每个项目基于的OpenStack版本都不一样，所以经常来回的安装部署OpenStack环境，比较繁琐，工作之余一直在寻求一种部署环境的便捷方式。目前比较主流的部署方式是devstack，也非常方便，但观察OpenStack的发展趋势，已经有越来越多的公司在做OpenStack的容器化部署，OpenStack社区也有对应的项目：kolla，虽然现在用的不是特别多，但利用容器产生的一些优势，相信在将来会有更多的公司采用容器化部署，本人在空闲时间尝试用kolla部署了一套mitaka版本的OpenStack环境（ALL IN ONE），以下是详细步骤，如果有任何问题也欢迎底下留言。
init外的属性是类属性，定义在init内的是对象属性metaclass 是创造类，而不是实例化类的对象metaclass中操作的属性都是类的属性metaclass中通过super().__new__创建新类metaclass中通过super().__new__创建的类包含了父类的属性，可以通过getattr获取metaclass中直接修改通过getattr获取的父类属性，会更新到父类中，影响所有父类的子类metaclass中，如果父类在init外定义了某个属性，这个属性可以通过getattr获取，且被继承到子类，否则通过getattr获取的结果为Nonemetaclass中，通过setattr设置类的属性，只作用在当前类，不会修改父类的属性cloud-init-local.servicecloud-init在安装的时候会在system-generators目录（例如：/usr/lib/systemd/system-generators/）下创建一个cloud-init-generator可执行文件，实际上是一个shell脚本。systemd在启动初期会执行该generator（目录下所有的generators都会在同一时间被并行执行 ）。在cloud-init-generator脚本中判断了当前是否需要启动cloud-init.target，一般会检查一下几点：
cloud-init是用来对云实例进行初始化配置的一个工具，目前支持很多云平台，例如OpenStack、AWS、ALiYun等。
在两个节点之间或两个时刻之间需要同步有顺序的资源，例如防火墙策略，如何用比较小的代价来实现资源一致。
有一种思路是类似文本比较，用diff的方法来修改待同步一侧的资源。
需要使用的python的lib库：difflib
AMQP 0-9-1（Advanced Message Queuing Protocol）高级消息队列协议是一个消息协议，它支持符合标准的客户端请求程序与符合标准的消息中间件代理进行通信。
被折磨了一个礼拜！！！你奶奶的！！！等空了，一定要抽时间把它里里外外翻个遍看看！！！
说道做到，今儿就来翻开monkey patch的大衣，看看里面到底是什么。
其实它一点都不神秘，挺简单的一个东西，但是当你不知道你的程序中被人打了猴子补丁的时候，你真的会疯掉，就像我一样，好东西要好好的用，不然全是一个个坑啊~_~ !!!