On Sun, Mar 31, 2019 at 11:27 PM Lingxian Kong <anlin.kong@gmail.com> wrote:
Hi,
I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train dev cycle. Since the master branch is open for contribution and review, for those who care about Trove, here are several things I'd like to bring to your attention and most importantly, need your feedback.
- Deprecate nova-network.
As I mentioned in the candidacy, The nova-network related code is spread in the repo, which makes it very difficult for new feature implementation and bugfix. Considering nova-network was deprecated in the OpenStack Newton release, I propose we also deprecate nova-network support in Trove and remove after several cycles according to the deprecation policy of the community. I'm not sure if there is still anyone using nova-network for Trove, especially in production. If yes, please reply to this email.
- Create service VM in admin project by default
Currently, Trove has configuration support to create the db instance in the admin project, which I think should be the default deployment model to reduce the security risk given all the db instances are communicating with RabbitMQ in the control plane.
- Remove SecurityGroup API extension
TBH, I don't know when and why that extension was added in Trove but since it's not included in Trove API document(https://developer.openstack.org/api-ref/database/), I assume there is on one relies on that in production, so should be safe to remove.
- Remove SecurityGroup related database model
I don't have the history development background in my mind, but IMHO, i don't think it's reasonable for Trove to maintain such information in db.
- Security group management enhancement
Removing the API extension and database model doesn't mean Trove shouldn't support security group for the db instance, on the contrary, security should always be the first thing we consider for new features. The two tasks above are actually prerequisites for this one. In order to make it easy to maintain and as more secure as possible, Trove is not going to allow the end user to manipulate the security group associated with db instance. Trove will try to provide as more information as possible to make the debugging and performance tuning easy.
- Monitoring capability
Currently, there is no monitoring capability support in Trove, and I think that's the only main part missing for Trove to be running in production. I don't have a full picture in mind now but will try to figure out how to achieve that.
- Priorities of the previous dev cycles
Of course, I shouldn't put the previous dev cycle priorities away from the track, e.g. the Stein dev cycle priorities are well documented here https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking
As Trove project has been experiencing some up and downs in the past, but it's still very useful in some deployment use cases and has some advantages over the container deployment model. As you could guess, the reason I raised my hand to lead Trove is that we(Catalyst Cloud) have been deploying Trove in production, so all those things are aiming at making Trove production ready, not only for private cloud but also for the public.
If you have any concerns related to what's mentioned above, please don't hesitate to reply. Alternately, I'm always in the #openstack-trove IRC channel and could answer any questions during the working hours of UTC+12.
I think another thing is the deployment model of relying on RabbitMQ to talk to the control plane. That has been the biggest sticking point for deployers. I think adopting something similar to the Octavia service VM model with public/private key and HTTP API might be far more successful.
I really appreciate any feedback from the community.
--- Cheers, Lingxian Kong Catalyst Cloud
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. http://vexxhost.com