[trove] Trove for Train

Lingxian Kong anlin.kong at gmail.com
Mon Apr 1 20:24:49 UTC 2019


Thanks for the advise, Mohammed :-)

The several differences between current Trove and Octavia communication
model are:

- The attack surface between database and haproxy is different, it's much
easier to hack database than haproxy. So the Octavia model is good, but
doesn't mean it's suitable for Trove as well.
- The Octavia guest agent normally doesn't initialize the communication
with the control plane, except for sending the monitoring status via UDP,
but Trove guest agent has to notify update back to control plane for
database status change. This could be changed though.

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Tue, Apr 2, 2019 at 6:33 AM Mohammed Naser <mnaser at vexxhost.com> wrote:

> On Sun, Mar 31, 2019 at 11:27 PM Lingxian Kong <anlin.kong at 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 at vexxhost.com
> W. http://vexxhost.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/a5f31023/attachment.html>


More information about the openstack-discuss mailing list