OpenStack Trove 路线图 — OpenStack Summit 2013

在OpenStack H版里Trove正式通过孵化器计划，加入了OpenStack Core Project。在H版里Trove主要完成了从之前Rackspace私有项目向着OpenStack靠拢的变化，比如RackSpace在内部维护了一系列私有的OpenStack项目如Nova，Cinder使得Trove本身的部分功能不能完全兼容OpenStack社区版。在H版本中非常多的BP努力让现有的Trove功能能在社区版也能生效，如H版实现的Implement resize volume method。还有加入Heat的整合，代码结构的重构等等。在I版中开始专注于功能上的增加，开始寻求能被实验环境下使用。

目前H版支持MySQL数据库的管理，通过启动一个指定大小预先安装MySQL镜像的VM，通过在VM里预装的Guest Agent实现对数据库的管理，如数据库、用户管理。同时，依赖于Nova和Cinder的Resize能力实现对数据库实例的变更功能。在I版中，Trove将会致力于提供更多的数据库选择如MongoDB，Redis和Cassandra。同时，将会与Heat进行更加紧密的连接来避免直接对接Nova、Cinder。

Moving Trove integration tests to Tempest

同时是历史遗留问题，Trove最初的整合测试不同于OpenStack官方的Tempest，使得开发者难以调试和提交新的整合测试。这次讨论了如何迁移并且保证I版开发进度不会受到大的影响。比如会将制作镜像的方式和注入Guest Agent都放到TripleO去，将旧的Trove整合测试仍然留着，但是以后的测试都使用Tempest

Trove Current Heat Integration

因为现在Heat成为了OpenStack的聚合服务，因此Trove作为一个DBaaS，也倾向于直接与Heat沟通而不是Cinder与Nova。但是面临的主要问题是Heat还远远未成熟并且目前能Work的API并不多，同时使用Heat以后很多API不再能直接控制后变得不可调，比如resize方法Heat会直接处理而不是等待Confirm。更多问题主要聚焦在如何利用Heat的Template并且满足Trove的需求。

Trove Datastore Clustering

Trove它的野心非常大，不仅希望满足多种数据库的管理，也希望能管理每种数据库的不同集群模式，如MySQL的主从或者主主模式。这次主要讨论了Trove的Clustering的API定义，如何构建一个通用的API来满足不同数据库后端的支持。详细的API定义在Trove-Replication-And-Clustering-API。

Downtime Trove Upgrades

主要实现Trove各个组件没有Downtime的升级，升级Trove数据库、Guest Agent、Trove task manager和API。目前希望实现方式通过Graceful Shutdown来慢慢停止消费新的消息，然后重新启动。Guest Agent将会自动更新当它收到更新请求时，这也使得Guest Agent会将数据库逻辑交给其他组件。

Guest Agents in Trove

现在的Guest Agent被认为是数据库在VM端的扩展用来执行各种命令配合Trove的API。主要讨论了Guest Agent的输入以及输出是否恰当，比如能否用其他消息通讯方式如XMPP，Http来替代RPC模式。并且需要减小Guest Agent的大小，现在的Guest Agent占据了200MB的大小。还有就是是否将Guest Agent迁移出去作为一个独立的Repo。

从以上讨论中我们可以看出，Trove正在越来越多的考虑实际生产环境下的使用，虽然在I版本中能够达到生产使用的可能性不是很大，但是我仍然对Trove有一个很好的期望，作为开源世界里不多的RDS实现非常具有吸引力。