Open Stack

On 4/1/19 3:24 PM, Lingxian Kong wrote:
> 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.

Doesn't that make it _more_ important for the database nodes to not have 
access to the control plane rabbitmq? If a VM gets compromised I'd much 
rather that it not have access to a core piece of my infrastructure.

> - 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 
> <mailto:mnaser at vexxhost.com>> wrote:
> 
>     On Sun, Mar 31, 2019 at 11:27 PM Lingxian Kong <anlin.kong at gmail.com
>     <mailto: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 <mailto:mnaser at vexxhost.com>
>     W. http://vexxhost.com
>