Open Stack

tl;dr
-----

The Trove team held its mid-cycle sprint in Raleigh, NC last week. My
thanks to Red Hat and Pete MacKinnon (IRC: pmackinn) who hosted us for
this mid-cycle meeting. Several attendees from companies active in the
project (HP, Tesora, IBM and Red Hat) attended the meeting in person and
remotely via teleconference. Our special thanks also goes to Kengo-san
and Masaki-san of NTT who made the trip all the way from Japan to attend
the mid-cycle.This summary is informational for those who were not able
to attend the meetup, and a reminder for those who had action items
assigned to them to get cracking. Unfortunately a number of them are
assigned to me so I'll be working through these for some time.

Details
-------

The agenda for the mid-cycle is online [1]. The meetings lasted two and
a half days and covered a variety of topics. Etherpads were maintained
for each of the sessions. The full list of attendees is available in the
"Introductions and Icebreakers" etherpad.

We reviewed most outstanding blueprints for projects that were committed
for the Mitaka release. At this point we believe that all projects are
on track to being merged in time for the release, with the exception of
one that is potentially in jeopardy of not making the deadline.
Significant outstanding bugs were reviewed and triaged.

We discussed review velocity and how some recent changes to our weekly
meetings have helped bring a focus to the reviews that are in the queue.
We discussed some approaches to improving the responsiveness to patches
that are in review as there have been some cases where significant
patches have sat for a long time without getting reviews. We concluded
that at the weekly meeting(s) we would highlight specific patches that
are in need of review and proactively get reviewers to look at them.

We reviewed (as a team) the specifications and in some cases the code
for some significant features that we seek to release in the Mitaka
timeframe. We found at a previous mid-cycle (Liberty) that having the
contributor(s) lead the team through the salient aspects of the review
considerably improved the value of the review, in some cases resulting
in comments and suggestions for improvement that could be quickly turned
around. We feel that this is a good model and will look to continue this
in the future. At a previous mid-cycle we discussed the possibility of
having this kind of meetings throughout the year; we have not yet done
that but it is something that, should the opportunity arise, we will
experiment with.

The projects we reviewed include:

- MariaDB GTID Replication
- MariaDB Clustering
- Cassandra User Functions
- Cassandra Configuration Groups
- Cassandra B&R
- Trove Module Management
- Vertica Cluster Grow and Shrink
- Implement DBaaS Ceilometer Notifications
- DB2 Backup and Restore

In addition, we discussed

- the process we wish to follow in graduating MongoDB and Redis
datastores which are currently deemed "experimental". The plan is to
create a non-voting gate and observe how it performs between now and
when we open Newton. Then we will move these datastores either to
tech-preview or stable based on the performance in the non-voting gate

- the need for a management client to provide a number of capabilities
that we need urgently in the project [SlickNik, amrith]

- the project to make it easier to build guest images. [pmackinn et al].
The plan is to write a specification to describe the effort, the new
repository that is to be created, the repository will contain the
elements required to build guest images, describe how those images would
be built, describe how this would relate to trove, to the existing
trove-integration repository, to the CI process, and so on

- the issues surrounding secure deployment of trove, and how this could
be improved [barclaac, amrith]. Related to this, we also discussed the
trove "superconductor", a project that could considerably improve the
capabilities of trove, while at the same time addressing many of the
security issues discussed.

- how to further improve the modularity of the code in the guest by
building an abstraction between the guest agent and the guest image [amrith]

- the issues surrounding upgrades and how we will handle those moving
forward

- the issues surrounding release notes

- python3 support. We reviewed our earlier conversations about this (at
a Trove meeting) and felt that given the things that were already
committed, that we should look to address python3 in the Newton cycle.
The wiki page for the python3 project was updated to indicate that the
project was in progress in trove

- a project to extend back-end (persistent storage) support for trove.
Currently only cinder is supported, the plan is to introduce several
others including manila.

Kengo-san and Masaki-san provided us with a description of the issues
that they are attempting to address in their OpenStack based DBaaS
platform and inquired about the suitability of trove for the purpose.
All of the things that they were looking for fell squarely within the
scope of the project and we welcome their ongoing participation, and
contributions to the project.

There were some topics that we still need to discuss and get to the
bottom of, which we were not able to do justice to at this meetup. Those
include

- how to deploy multiple datastores using the same manager, a current
limitation

- how we will get to a v2 API for Trove, and the growing list of things
that we'd like to see in that new API

- migrating to the openstack client

- refactor user/database extensions for non-MySQL datastores

- supporting a trove capabilities API

On the whole, a good time was had by all (to the best of my knowledge,
no one told me otherwise ;)). My thanks again to Red Hat, and to Pete
who hosted us at the Red Hat offices in Raleigh, and those who
participated in the meeting.

Thanks,

-amrith

[1] https://wiki.openstack.org/wiki/Sprints/TroveMitakaSprint

--
Amrith Kumar, CTO                   | amrith at tesora.com
Tesora, Inc                         | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140                | GPG: 0x5e48849a9d21a29b 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160219/0f92d1dc/attachment.pgp>