<font size=2 face="Arial">Amrith: Some comments regarding the scarcity
of deployments, and the proposed approach.</font><br><br><font size=2 face="Arial">We know of multiple teams that are now independently
charging down and investing in a Trove path.  They are at various
stages of deployment and are beyond tire-kicking. They are beginning to
build dev/test environments, some are building commercial products, and
we fully expect some people to be in production with Trove by the end of
the year.  Collectively, we need to start bridging and engaging these
people into the Trove community.  <br><br>We also strongly believe that we need an evolutionary approach to moving
Trove forward vs. the revolutionary approach that is being proposed.  Our
deeply held view is that it is feasible and rationale to evolve Trove as
it exists today.  We agree that there are architectural issues that
have to be addressed.   Let's start working on addressing these issues
as well as the current currency issues but in a evolutionary way.  The
revolutionary approach will halt all progress and set a bad precedent,
and we believe that it will cause people to walk away from the community
and likely OpenStack as well. </font><br><br><font size=2 face="Arial">- Manoj</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Amrith Kumar <amrith.kumar@gmail.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">06/18/2017 06:41 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[openstack-dev]
[trove][all][tc] A proposal to rearchitect Trove</font><br><hr noshade><br><br><br><font size=3 face="Courier">Trove has evolved rapidly over the past
several years, since integration in IceHouse when it only supported single
instances of a few databases. Today it supports a dozen databases including
clusters and replication.<br><br>The user survey [1] indicates that while there is strong interest in the
project, there are few large production deployments that are known of (by
the development team).<br><br>Recent changes in the OpenStack community at large (company realignments,
acquisitions, layoffs) and the Trove community in particular, coupled with
a mounting burden of technical debt have prompted me to make this proposal
to re-architect Trove.<br><br>This email summarizes several of the issues that face the project, both
structurally and architecturally. This email does not claim to include
a detailed specification for what the new Trove would look like, merely
the recommendation that the community should come together and develop
one so that the project can be sustainable and useful to those who wish
to use it in the future.<br><br>TL;DR<br><br>Trove, with support for a dozen or so databases today, finds itself in
a bind because there are few developers, and a code-base with a significant
amount of technical debt.<br><br>Some architectural choices which the team made over the years have consequences
which make the project less than ideal for deployers.<br><br>Given that there are no major production deployments of Trove at present,
this provides us an opportunity to reset the project, learn from our v1
and come up with a strong v2.<br><br>An important aspect of making this proposal work is that we seek to eliminate
the effort (planning, and coding) involved in migrating existing Trove
v1 deployments to the proposed Trove v2. Effectively, with work beginning
on Trove v2 as proposed here, Trove v1 as released with Pike will be marked
as deprecated and users will have to migrate to Trove v2 when it becomes
available.<br><br>While I would very much like to continue to support the users on Trove
v1 through this transition, the simple fact is that absent community participation
this will be impossible. Furthermore, given that there are no production
deployments of Trove at this time, it seems pointless to build that upgrade
path from Trove v1 to Trove v2; it would be the proverbial bridge from
nowhere.<br><br>This (previous) statement is, I realize, contentious. There are those who
have told me that an upgrade path must be provided, and there are those
who have told me of unnamed deployments of Trove that would suffer. To
this, all I can say is that if an upgrade path is of value to you, then
please commit the development resources to participate in the community
to make that possible. But equally, preventing a v2 of Trove or delaying
it will only make the v1 that we have today less valuable.<br><br>We have learned a lot from v1, and the hope is that we can address that
in v2. Some of the more significant things that I have learned are:<br><br>- We should adopt a versioned front-end API from the very beginning; making
the REST API versioned is not a ‘v2 feature’<br><br>- A guest agent running on a tenant instance, with connectivity to a shared
management message bus is a security loophole; encrypting traffic, per-tenant-passwords,
and any other scheme is merely lipstick on a security hole<br><br>- Reliance on Nova for compute resources is fine, but dependence on Nova
VM specific capabilities (like instance rebuild) is not; it makes things
like containers or bare-metal second class citizens<br><br>- A fair portion of what Trove does is resource orchestration; don’t reinvent
the wheel, there’s Heat for that. Admittedly, Heat wasn’t as far along
when Trove got started but that’s not the case today and we have an opportunity
to fix that now<br><br>- A similarly significant portion of what Trove does is to implement a
state-machine that will perform specific workflows involved in implementing
database specific operations. This makes the Trove taskmanager a stateful
entity. Some of the operations could take a fair amount of time. This is
a serious architectural flaw<br><br>- Tenants should not ever be able to directly interact with the underlying
storage and compute used by database instances; that should be the default
configuration, not an untested deployment alternative<br><br>- The CI should test all databases that are considered to be ‘supported’
without excessive use of resources in the gate; better code modularization
will help determine the tests which can safely be skipped in testing changes<br><br>- Clusters should be first class citizens not an afterthought, single instance
databases may be the ‘special case’, not the other way around<br><br>- The project must provide guest images (or at least complete tooling for
deployers to build these); while the project can’t distribute operating
systems and database software, the current deployment model merely impedes
adoption<br><br>- Clusters spanning OpenStack deployments are a real thing that must be
supported<br><br>This might sound harsh, that isn’t the intent. Each of these is the consequence
of one or more perfectly rational decisions. Some of those decisions have
had unintended consequences, and others were made knowing that we would
be incurring some technical debt; debt we have not had the time or resources
to address. Fixing all these is not impossible, it just takes the dedication
of resources by the community.<br><br>I do not have a complete design for what the new Trove would look like.
For example, I don’t know how we will interact with other projects (like
Heat). Many questions remain to be explored and answered.<br><br>Would it suffice to just use the existing Heat resources and build templates
around those, or will it be better to implement custom Trove resources
and then orchestrate things based on those resources?<br><br>Would Trove implement the workflows required for multi-stage database operations
by itself, or would it rely on some other project (say Mistral) for this?
Is Mistral really a workflow service, or just cron on steroids? I don’t
know the answer but I would like to find out.<br><br>While we don’t have the answers to these questions, I think this is a
conversation that we must have, one that we must decide on, and then as
a community commit the resources required to make a Trove v2 which delivers
on the mission of the project; “To provide scalable and reliable Cloud
Database as a Service provisioning functionality for both relational and
non-relational database engines, and to continue to improve its fully-featured
and extensible open source framework.”[2]<br><br>Thanks,<br><br>-amrith​<br><br><br>[1] </font><a href=https://www.openstack.org/assets/survey/April2017SurveyReport.pdf><font size=3 color=blue face="Courier"><u>https://www.openstack.org/assets/survey/April2017SurveyReport.pdf</u></font></a><font size=3 face="Courier"><br>[2] </font><a href=https://wiki.openstack.org/wiki/Trove#Mission_Statement><font size=3 color=blue face="Courier"><u>https://wiki.openstack.org/wiki/Trove#Mission_Statement</u></font></a><br><font size=3><br></font><tt><font size=2>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>