今天解了一个hyperV的bug，大概了解了一下在部署虚机的时候，创建网络设备的过程，在这里记录一下。
以hyperV为例，在controller创建虚拟机的时候，
1.虚拟机的状态会先变成networking，这个时候，controller其实还没有跟compute上的neutron-hyperv-agent交互，而只是在数据库里建立一下网络设备的记录而已。比如，虚拟网卡（port）的信息：ip，网络id，segment id等。
2.接下来，虚拟机的状态会变成spawning。这个时候，controller开始往compute上拷贝文件。代码可以参见nova/virt/hyperv/vmops.py:VMOps.spawn(). 从这个方法里可以清楚的看到spawn的过程。创建虚拟机实例的方法也是在这里被调用的。而在创建虚拟机的最后一步，就是关于网络设备的创建。先创建一个虚拟网卡（nic），然后把这个虚拟网卡绑定到新创建出来的实例上。
3.在neutron/plugins/hyperv/agent/hyperv_neutron_agent.py的HyperVNeutronAgent类里，有一个方法叫做deamon_loop()。这个方法在agent启动的时候，就一直不停的执行，一直到agent死掉为止。在这个方法里，会不停的检测port，不管是被删除的port还是刚被添加进来的port。所以，在步骤2里，我们创建的虚拟网卡在这里被检测到，然后会按照添加一个port的方法（_treat_devices_added）来处理。这个方法会调用neutron/agent/rpc.py向controller发送一个请求来获得这个虚拟网卡的相关信息。controller接到这个请求后，会让core_plugin来处理。现在，我们一般都用ml2来做core_plugin。所以neutron/plugins/ml2/rpc.py会来响应这个请求，并做一系列得处理，然后把结果返回给hyperv
 agent端。
 
有兴趣的同学可以自己跟一下代码，就可以了解这个部署的过程。

控制干系人参与是全面监督项目干系人之间的关系，调整策略和计划，以调动干系人参与的过程。 本过程的主要作用是， 随着项目进展和环境变化， 维持并提升干系人参与活动的效率和效果。

控制干系人参与

    输出

        工作绩效信息

        变更请求

        项目管理计划更新

        项目文件更新

        组织过程资产更新

    输入

        项目管理计划

        问题日志

        工作绩效信息

        项目文件

    工具技术

        信息管理系统

        专家判断

        会议

管理干系人参与是在整个项目生命周期中，与干系人进行沟通和协作，以满足其需要与期望，解决实际出现的问题，并促进干系人合理参与项目活动的过程。 本过程的主要作用是，帮助项目经理提升来自干系人的支持， 并把干系人的抵制降到最低，从而显著提高项目成功的机会。

 
管理干系人参与

    输出

        问题日志

        变更请求

        项目文件更新

        组织过程资产更新

        项目管理计划更新

    输入

        干系人管理计划

        沟通管理计划

        变更日志

        组织过程资产

    工具技术

        沟通方法

        人际关系技能

        管理技能

文章目录
1:评审的过程
2：评审内容
3：参与评审人员（这里会分为多个级别进行评审）

1:评审的过程
  A:开始前做好如下准备
                1、确定需要评审的原因
                2、确定进行评审的时机
                3、确定参与评审人员
                4、明确评审的内容
                5、确定评审结束标准
               6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
                7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
                8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
   B：开始评审
                1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
                2、 通用邮件与相关人员沟通
                3、 通用IM工具直接与相关人员交流
                4、根据评审内容进行评审

2：评审内容
    1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
    2、 优先极安排是否合理。
    3、 是否覆盖测试需求上的所有功能点。
    4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
    5、 是否已经删除了冗余的用例。
    6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
    7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
   8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

3：参与评审人员（这里会分为多个级别进行评审）
   1、 部门评审，测试部门全体成员参与的评审。
   2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
   3、 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见