<font size=2 face="sans-serif">Amrith, </font><br><br><font size=2 face="sans-serif">See answers to your questions below.</font><br><br><font size=2 face="sans-serif">Cheers,</font><br><font size=2 face="sans-serif">Luke  </font><br><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> I understand that the Trove
project will be going into maintenance mode</font><br><font size=2 face="sans-serif">>> soon. I have a number of Trove
related enhancements and bug fixes that I</font><br><font size=2 face="sans-serif">>> would like to submit to the
community, but I don't know if they would be</font><br><font size=2 face="sans-serif">>> considered given that the project
is going into maintenance mode. Please</font><br><font size=2 face="sans-serif">>> elaborate on what you mean
by maintenance mode.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> ​See: </font><a href=https://review.openstack.org/#/c/488947/><font size=2 face="sans-serif">https://review.openstack.org/#/c/488947/</font></a><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> It is not a foregone conclusion
that the project will go into maintenance</font><br><font size=2 face="sans-serif">> mode. Thierry and I (for example)
are not convinced that this is the right</font><br><font size=2 face="sans-serif">> course of action, but if there
are no offers to contribute to the project,</font><br><font size=2 face="sans-serif">> it may be a decision by default.</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> Do you subscribe to the OpenStack-dev
mailing list​. Please also see</font><br><font size=2 face="sans-serif">> </font><a href=http://openstack.markmail.org/thread/4p6gp263fei4mbru><font size=2 face="sans-serif">http://openstack.markmail.org/thread/4p6gp263fei4mbru</font></a><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> Finally, for a description of what
maintenance mode means, please refer:</font><br><font size=2 face="sans-serif">> </font><a href=https://governance.openstack.org/tc/reference/tags/status_ma><font size=2 face="sans-serif">https://governance.openstack.org/tc/reference/tags/status_ma</font></a><br><font size=2 face="sans-serif">> intenance-mode.html</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> Would Trove be updated to support
new OpenStack versions?</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> Would support be provided for Trove
gate testing?</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> Would elements be enhanced to support
Xenial and newer versions of</font><br><font size=2 face="sans-serif">>> databases?</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> Is there a time limit associated
with maintenance mode? For example, would</font><br><font size=2 face="sans-serif">>> it remain in effect for a year
or two after the new stuff is released?</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> ​For the four questions above,
I direct your attention to the definition</font><br><font size=2 face="sans-serif">> of the maintenance-mode tag (</font><a href=https://governance.openstack/><font size=2 face="sans-serif">https://governance.openstack</font></a><font size=2 face="sans-serif">.</font><br><font size=2 face="sans-serif">> org/tc/reference/tags/status_maintenance-mode.html)
and remind you that</font><br><font size=2 face="sans-serif">> support for different versions
from the community, for gate testing and for</font><br><font size=2 face="sans-serif">> elements is dependent on people
participating (and their employers allowing</font><br><font size=2 face="sans-serif">> them to do this). At this point,
I have no one who has stepped up to do</font><br><font size=2 face="sans-serif">> this in any significant way. There
are a couple of people from China Mobile</font><br><font size=2 face="sans-serif">> who want to help but who are largely
in the weeds, trying to fix this and</font><br><font size=2 face="sans-serif">> that bug but have no idea what
Trove is all about. IBM has a core reviewer</font><br><font size=2 face="sans-serif">> on the project ​(Mariam is copied
on this email). I am happy that she's</font><br><font size=2 face="sans-serif">> able to devote what time she can
to the project but absent competent</font><br><font size=2 face="sans-serif">> reviewers, whether your changes
ever get merged or not remains an</font><br><font size=2 face="sans-serif">> interesting question. Since you
will be contributing elements and propose</font><br><font size=2 face="sans-serif">> to contribute a tool, will you
be (or will IBM be) offering to support it?</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>  Let me provide some back
ground on my code changes, so you will have a</font><br><font size=2 face="sans-serif">> better idea of what might be submitted
in a patch.</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> I have written a fully automated
command that creates a virtual guest</font><br><font size=2 face="sans-serif">>> image based on Ubuntu 16.04
containing a user specified version of a</font><br><font size=2 face="sans-serif">>> database. The user's selection
is validated against an internal list of</font><br><font size=2 face="sans-serif">>> databases built into the tool.
Once validated, the tool creates the image,</font><br><font size=2 face="sans-serif">>> registers it with Glance, and
then creates a Trove Datastore definition for</font><br><font size=2 face="sans-serif">>> it. This is done in a single
command invocation that typically takes about</font><br><font size=2 face="sans-serif">>> 25 minutes to complete. For
some of the databases, it takes considerably</font><br><font size=2 face="sans-serif">>> longer (2 hours for mongodb)
as I have to compile source code. The guest</font><br><font size=2 face="sans-serif">>> image that is produced is complete
from a Trove perspective. It includes</font><br><font size=2 face="sans-serif">>> the Cloud specific trove-guestagent.conf
file and SSH public keys for the</font><br><font size=2 face="sans-serif">>> DBA and OpenStack controller
nodes.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> ​What mechanism does it use
to develop the image? is it diskimage-builder</font><br><font size=2 face="sans-serif">> or some other?</font><br><br><font size=2 face="sans-serif">Yes, diskimage-builder and Trove elements</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> Is there something the matter with
the existing tool that exists, it</font><br><font size=2 face="sans-serif">> already works, it does more than
just build an image, and it is already</font><br><font size=2 face="sans-serif">> integrated in the gate. Why not
use that?​</font><br><br><font size=2 face="sans-serif">Is your question why don't we use trovestack?
   If so, we were looking for</font><br><font size=2 face="sans-serif">something that was more streamlined
with fewer dependencies.   The tool</font><br><font size=2 face="sans-serif">would need to interface with the client's
cloud.   Our tool is directed at</font><br><font size=2 face="sans-serif">customers and IBM lab based services,
neither of whom is expected to be</font><br><font size=2 face="sans-serif">an OpenStack or Trove expert.</font><br><br><font size=2 face="sans-serif">Beyond that, there is a difference in
how are images our built.   First, we need</font><br><font size=2 face="sans-serif">to control which versions of databases
are built as opposed to letting the stack</font><br><font size=2 face="sans-serif">determine that.    ppc64le
support in the database communities is at varying</font><br><font size=2 face="sans-serif">stages.   In some cases, there
are packages and in others there are not.  In</font><br><font size=2 face="sans-serif">addition, there are specific versions
that we have tested and enhanced from</font><br><font size=2 face="sans-serif">a performance perspective that we would
like to include in our offering. </font><br><font size=2 face="sans-serif">  </font><br><font size=2 face="sans-serif">The second part of this is related to
the Trove Guest Agent.   We needed to</font><br><font size=2 face="sans-serif">make a few code changes to support different
versions and to fix bugs that</font><br><font size=2 face="sans-serif">we have found.   Anyway, this led
to us carrying patches in the tool, which is</font><br><font size=2 face="sans-serif">part of a broader strategy to stage
our database deliverables.   We would</font><br><font size=2 face="sans-serif">like to add support for new databases
over time.   To deliver these to our</font><br><font size=2 face="sans-serif">clients without them having to re-install
Trove on the controller side.</font><br><font size=2 face="sans-serif">Fundamentally, this means isolating
the database specific log to the Trove</font><br><font size=2 face="sans-serif">Guest Agent and Trove elements.  
</font><br><br><font size=2 face="sans-serif">So, this is a rather long explanation,
but that is why we couldn't use Trovestack</font><br><font size=2 face="sans-serif">or the existing tools as is.  
There are external considerations such as the</font><br><font size=2 face="sans-serif">state of the database communities and
delivery strategies that warranted</font><br><font size=2 face="sans-serif">a slightly different approach. </font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> ​</font><br><font size=2 face="sans-serif">> This approach is nice (having a
full guest image with the guest agent and</font><br><font size=2 face="sans-serif">> all that but as you observe, it
takes about 2 hours per build and from a</font><br><font size=2 face="sans-serif">> developers perspective, this is
a pain.</font><br><br><font size=2 face="sans-serif">It takes 2 hours to build mongodb, because
there is no package provided </font><br><font size=2 face="sans-serif">by the community for ppc64le.  
In general, it takes 25 minutes to generate</font><br><font size=2 face="sans-serif">images and create the datastore.  
 I expect that the times are roughly the</font><br><font size=2 face="sans-serif">same as with the existing tools. </font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> I assume that the tool is therefore
for production use cases.</font><br><br><font size=2 face="sans-serif">Our offering is intended for development
use only, but it is a big step</font><br><font size=2 face="sans-serif">in the direction of production use cases.
  The images are built for specific</font><br><font size=2 face="sans-serif">users in a more prescribed manner.</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> Could the elements that you have
developed be used with the existing tool</font><br><font size=2 face="sans-serif">> or is your tool a complete replacement
for the one that already exists?​</font><br><br><font size=2 face="sans-serif">With a little bit of work they may be
used with the existing tool.   I am not </font><br><font size=2 face="sans-serif">planning on replacing existing tools.
  In fact, I wasn't planning on dropping</font><br><font size=2 face="sans-serif">the new tool but I would if there is
interest.   The new tool is at a public</font><br><font size=2 face="sans-serif">which I noted in my original note.</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> ​Is there some reason that this
tool was not developed in the open, using</font><br><font size=2 face="sans-serif">> the normal open development process?</font><br><br><font size=2 face="sans-serif">We were working towards a short release
schedule for our new OpenDBaaS offering.</font><br><font size=2 face="sans-serif">It took three months to develop the
tool and provide support for 5 databases,</font><br><font size=2 face="sans-serif">including multiple versions of some
of them.   This is our second step</font><br><font size=2 face="sans-serif">to engage with the community. </font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> There are ways to accelerate the
compiling of source code and such through</font><br><font size=2 face="sans-serif">> the use of image layers (if you
are using DIB). I have elements and code</font><br><font size=2 face="sans-serif">> that will build most of the trove
elements in minutes and I'm waiting to</font><br><font size=2 face="sans-serif">> see whether there is any point
in contributing them to the upstream or not,</font><br><font size=2 face="sans-serif">> at this point. I could show you
how to do that, and it would be awesome to</font><br><font size=2 face="sans-serif">> have you build your tool into the
build process somehow. That would be a</font><br><font size=2 face="sans-serif">> win-win for all ...​</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> I also have commands that setup
Nova flavors on a per database basis.</font><br><font size=2 face="sans-serif">>> These flavors can be customized
by the user before they are instantiated in</font><br><font size=2 face="sans-serif">>> the cloud.That's good to hear.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> ​The existing command (trovestack)
already does this.​</font><br><br><font size=2 face="sans-serif">I didn't see that in the Trovestack.
  Does it allow the user to customize</font><br><font size=2 face="sans-serif">the values.   Can you provide a
 provide a link?</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> I wouldn't expect to drop these
commands to the Trove community. Only the</font><br><font size=2 face="sans-serif">>> changes to the Trove-guestagent
and elements enabling databases.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> Here's the list of databases
that are currently supported for ppc64le. In</font><br><font size=2 face="sans-serif">>> some cases, I have had to add
Xenial support.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> mariadb 10.1 --- package comes
from the community</font><br><font size=2 face="sans-serif">>> mongodb 3.4 community edition
--- source code from the community is</font><br><font size=2 face="sans-serif">>> compiled as there is no ppc64le
package</font><br><font size=2 face="sans-serif">>> mongodb 3.4 enterprise edition
--- package comes from community</font><br><font size=2 face="sans-serif">>> mysql 5.7 --- package comes
from Ubuntu 16.04. percona-xtrabackup-24 is</font><br><font size=2 face="sans-serif">>> compiled as there is no power
support in community</font><br><font size=2 face="sans-serif">>> postgresql 9.5 --- package
comes from Ubuntu 16.04</font><br><font size=2 face="sans-serif">>> postgresql 9.6 --- package
comes from community</font><br><font size=2 face="sans-serif">>> redis 3.0 --- package comes
from Ubuntu 16.04</font><br><font size=2 face="sans-serif">>> redis 3.2 --- source code from
the community is compiled</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> ​Why not just contribute the
elements to the existing project and have the</font><br><font size=2 face="sans-serif">> current tool use them?​</font><br><br><font size=2 face="sans-serif">That is my plan.</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> ​What of other databases currently
supported? galera cluster (pxc),</font><br><font size=2 face="sans-serif">> vertica, db2, percona, couchdb,
and couchbase?</font><br><br><font size=2 face="sans-serif">I haven't messed with them.   My
changes are hidden under environment</font><br><font size=2 face="sans-serif">variables so the absence of environment
variables should yield the old code.</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> My element related code changes
add environment variables that control</font><br><font size=2 face="sans-serif">>> the database version, the source
of the database software (distro,</font><br><font size=2 face="sans-serif">>> community, enterprise), and
logging options. In this way, the logic in the</font><br><font size=2 face="sans-serif">>> element is more generalized
and can be made to support multiple versions. I</font><br><font size=2 face="sans-serif">>> also added an environment variable
that specifies the name of the source</font><br><font size=2 face="sans-serif">>> package to be downloaded and
compiled when that is applicable. I also have</font><br><font size=2 face="sans-serif">>> environment variables to enable
database and trove guest agent logging.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> ​Which is nice except that your
guest agent code may or may not know how</font><br><font size=2 face="sans-serif">> to deal with that.​</font><br><br><font size=2 face="sans-serif">The guest agent and image logic are
coordinated.  </font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> My trove-guestagent code changes
are mostly about not reconfiguring the</font><br><font size=2 face="sans-serif">>> database with configuration
data remotely passed to it from the task</font><br><font size=2 face="sans-serif">>> manager. My code changes are
isolated to the prepare step. This logic looks</font><br><font size=2 face="sans-serif">>> something like: if database
version x, add or remove configuration</font><br><font size=2 face="sans-serif">>> parameter. Note there is relatively
very little of this code, ~150 LOCs, as</font><br><font size=2 face="sans-serif">>> database configuration parameters
rarely change. Note there is already some</font><br><font size=2 face="sans-serif">>> of this DB version specific
logic in the trove guest agent, so I am just</font><br><font size=2 face="sans-serif">>> adding more of it. But I believe
a better way is not to alter the database</font><br><font size=2 face="sans-serif">>> configuration data when the
database is fully configured in a Trove</font><br><font size=2 face="sans-serif">>> compliant manner via elements.
This would be implemented through a new</font><br><font size=2 face="sans-serif">>> command argument to the Trove
Guest agent which says ignore configuration</font><br><font size=2 face="sans-serif">>> changes. It would be set by
the elements as well.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> ​Hard to say whether this is
a good approach or not with out more detail.​</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> I haven't looked into the scale
out configuration data yet, but this can</font><br><font size=2 face="sans-serif">>> be handled differently as required.</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> ​Not sure what you mean.</font><br><br><font size=2 face="sans-serif">I was talking about the database cluster
configuration code which is a future</font><br><font size=2 face="sans-serif">deliverable for our offering.  
We are starting simple and will incrementally expand the</font><br><font size=2 face="sans-serif">offering as time goes by.    
 </font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> ​</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>> So, are these the sorts of
changes that I could add in a maintenance</font><br><font size=2 face="sans-serif">>> release?</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> ​Maintenance release of what,
trove? Are you asking whether these changes</font><br><font size=2 face="sans-serif">> can be made in a stable branch?
if yes, which branch? See</font><br><font size=2 face="sans-serif">> </font><a href="https://docs.openstack.org/project-team-guide/stable-branches.html"><font size=2 face="sans-serif">https://docs.openstack.org/project-team-guide/stable-branches.html</font></a><font size=2 face="sans-serif">and</font><br><font size=2 face="sans-serif">> the section "Appropriate Fixes".​</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>> 1) conditionally disable the
dynamic installation and configuration of</font><br><font size=2 face="sans-serif">>> database software in the trove-guest
agent via a new command argument</font><br><font size=2 face="sans-serif">>> 2) add environment variables
to trove elements enabling multiple versions</font><br><font size=2 face="sans-serif">>> of databases to be installed
and configured</font><br><font size=2 face="sans-serif">>> 3) add environment variables
to trove elements to enable database and</font><br><font size=2 face="sans-serif">>> trove-guest agent logging</font><br><font size=2 face="sans-serif">>> 4) add xenial support to elements</font><br><font size=2 face="sans-serif">>> 5) compiling source code in
elements for missing stack elements for</font><br><font size=2 face="sans-serif">>> ppc64le</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> These changes are implemented
at: </font><a href="https://github.com/open-power-"><font size=2 face="sans-serif">https://github.com/open-power-</font></a><br><font size=2 face="sans-serif">>> ref-design-toolkit/os-services/tree/master/osa/dbaas/dbimage-builder</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">> ​OK, so this is a whole new tool,
sure you can propose it but how do we</font><br><font size=2 face="sans-serif">> make sure that it gets integrated
into the current testing/gate? If you</font><br><font size=2 face="sans-serif">> want to drop this then I'd also
have to assume that there would be some</font><br><font size=2 face="sans-serif">> code that would make it part of
the current gate, and ideally make it</font><br><font size=2 face="sans-serif">> generate the images for the current
gate. But for that, the fact that you</font><br><font size=2 face="sans-serif">> install the guest agent onto the
image is a serious drag.</font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">> Also, why this wasn't proposed
as a blueprint or spec in the upstream so</font><br><font size=2 face="sans-serif">> it could be developed in the open,
I don't quite understand. After all, you</font><br><font size=2 face="sans-serif">> are now showing up with a complete
tool and asking that it be included</font><br><font size=2 face="sans-serif">> which largely runs counter to the
whole notion of open development, at</font><br><font size=2 face="sans-serif">> least as I understand it.​</font><br><font size=2 face="sans-serif">></font><br><br><font size=2 face="sans-serif">Above, in my original node, I said that
I was only planning on dropping code</font><br><font size=2 face="sans-serif">changes  to the element and that
I had a small design change to the guest agent</font><br><font size=2 face="sans-serif">that I would pursue with the community.
  I am not proposing to drop the </font><br><font size=2 face="sans-serif">tool, unless there was interest in that
from the community.    </font><br><br><font size=2 face="sans-serif">> ​</font><br><font size=2 face="sans-serif">> Finally, once committed, do you
(or IBM) commit to maintaining this code</font><br><font size=2 face="sans-serif">> and fixing bugs in it should they
arise, and upgrade/update it from time to</font><br><font size=2 face="sans-serif">> time?</font><br><font size=2 face="sans-serif">></font><br><br><font size=2 face="sans-serif">Yes</font><br><br><font size=2 face="sans-serif">></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>> Thanks, Luke Browning</font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">>></font><br><font size=2 face="sans-serif">></font><BR>