Open Stack

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 really appreciate any feedback from the community.

---
Cheers,
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/3b3be934/attachment-0001.html>