2016，依旧是坚定自己心中所想的本性
2017，希望自己所有的一切全部初始化
月份：2016年12月
Tempest测试类型解析：满屏装饰器
刚刚开始看openstack或者tempest的人，会发现都是装饰器，所以要抱着激情的态度来迎合它，而不是抵触，相信多看个几次就会慢慢习惯了
还是先看前面老是提起的flavor这个case
@attr(type='smoke')
def test_list_flavors(self):
# List of all flavors should contain the expected flav[......]
Tempest框架RESTful流程：HTTP接口组装终极无脑版
Tempest里进行接口测试，有API HTTP的，也有Command Line的，这里简单看下API层面HTTP RESTful的调用流程
这里随便看一个tempest里的test case，比如还是test_flavors.py里
@attr(type='smoke')
def test_list_flavors(self):
# List of all flavors should co[......]
OpenStack CI持续集成测试
社区OpenStack持续集成相关，这作者写得很详细清晰，直接COPY过来了，传送门标明原出处：http://stackeye.com/2014/06/openstack-ci/
本文档主要对Openstack社区目前的CI测试环境及其中用到的各个组件进行介绍。
测试的分类及必要性
测试的分类
测试的过程没太有太严格的分类标准，从使用的角度，我们可以从以下两个角度对测试进行分类。
按照测试过程[……]
Tempest里create_test_server方法的调用问题
昨天在测试一个简单nova接口的时候，只要是有继承base.py里的BaseComputeTest类，create_test_server函数这个case就会被默认执行，而假如测试的OpenStack环境不支持不带网卡创建虚拟机，就会报错，还是这个函数
@classmethod
def create_test_server(cls, **kwargs):
"""Wrapper utility[......]
测试框架Tempest进阶：第一坑一头雾水
对于OpenStack里API接口的测试，由于按需一直在变，云网络接口相对较少，一直放在持续集成测试中，而云主机部分接口实在太多，涉及到的模块也多，而主机部分大多生命周期操作以及验证都还涉及到多个物理节点，因此目前仅仅在一整个OpenStack环境通过整体功能回归验证其正确性，而对于接口层验证目前还是比较老，供提交代码之后来触发的接口测试，而对于新增功能接口，都没有实时添加进去，更甚之由于更新频率[……]
QEMU升级新版本引起的异常
正常情况下，节点上更新qemu版本，虚拟机都会进行关机再开机，因为qemu进程需要重启，但真正实际生活中，虚拟机里可能运行着比较重要的业务，中断会影响流水，甚至如果出现耗时很久才重新恢复服务影响就十分大，因此开发了新qemu版本，能够在虚拟机都不关机的情况下，进行上线更新qemu
在更新完之后，出现了一个小异常，因为本身就在测试上线过程，因此记录一下
最先一哥们的虚拟机表示不能使用了，看了下VM信[……]
Neutron Port之binding_failed
Neutron Port在使用过程中，甚至在带网络创建虚拟机的时候，有时候会出现binding_failed的问题，当然如果是创建虚拟机的时候出现，虚拟机状态就会使ERROR，如果仅仅是PORT的binding:vif_type字段变成binding_failed，那么连通性就会出现问题，总的来说这都是出现问题，正常情况下原因有很多，比如Open vSwitch agent没有alive，或者没有[……]
VIF Broadcast报文限速减少广播攻击
对于云环境里，如果是租户私有资源，同一广播域里出现大量广播包也不会对其他租户产生影响，因为相互隔离，而对于flat网络比如外网来说，由于是公用资源，假如出现持续广播报文，那么对同一广播域里其它用户的使用就会带来影响，比如出现以下报文
23:17:50.701992 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),[......]