1.记录每个用例执行的时间，内存使用情况，cpu使用情况，可以为性能测试提供帮助（可以通过监控软件或者写程序获得，时间是最重要的，还要考虑监控数据的传输问题）。
2.采用多任务中心的方式可以避免单节点故障，同时便于管理，可以有不同形式的分支代码任务中心支持不同的组。（通过ip来定位虚拟机，内部ip还是外部ip这需要测试，或者可以定义两者的映射关系）
3.记录每个实例最后获取test的时间可以帮助判断虚拟机是否挂掉，或者test运行是否挂掉。
4.可以用消息队列重写原先代码，也可以直接用原先代码，增加的功能如写数据库用消息队列。
5.对于超时脚本，关闭虚拟机再开一台，同时保存虚拟机的最后状态（cpu内存test信息）便于分析原因。
6.各个任务中心的数据库记录各自的情况，整体运行完成以后再将数据拷贝到中心数据库。
7.将机器分成各个aggregate，一个任务中心对应一个aggregate中的所有机器，便于镜像的本地缓存提高启动实例的速度，减少镜像的拷贝时间，可以做“金手指“（base img）。（可能要自己定义本地缓存的存储与删除策略（本地磁盘空间有限））（aggregate可以动态灵活配置，scheduler策略定义更灵活方便，一个运行任务的实例要集中在aggregate中开启，要预先定义（通过一定的算法策略）要开启的虚拟机数量推出要用到的物理机数量动态生成aggregate放入主机，不同的物理机配置可能不同需要定义一套虚拟机物理机数量对应算法，要写自己的策略，aggregate也可以预先定义成池）。
8.创建实例时在MetaData中直接写入数据，包括指定要访问的任务中心等。实例在开启以后首先通过访问一个服务，来获取自己的MetaData写入指定的文件。（Windows镜像好像不能直接注入文件可以再研究一下（应该是可以但这也是一种思路））
9.任务需要通过一个配置文件，配置一个模版工作流（可以用joson，或xml的形式），配置内容包括任务中心类型，所需镜像，所需软件，配套软件等相关的功能。可以定义一个任务中心池，不一定每次都关掉。
9.可以集成keystone的验证。
10.定义资源的概念，镜像相关，硬盘多大可以存几个镜像（拷贝镜像比较花时间），机子上有某个镜像缓存作为资源的主要特性。
11.ceph做后台分布式镜像存储。
12.考虑使用卷做持久化存储。
13.可以考虑文件注入，直接在镜像中注入一些代码或相关配置信息。
14.项目组提出的需求，任务可以暂停重启（可能需要序列化与反序列化），这个牵涉到任务中心代码的修改。可以实现服务器的负载均衡。
15.实现负载均衡加机器。
16.参考heat项目，实现自定义模版。
17.参考ceilometer项目实现计费功能。