Meetings/TroveMeeting
< Meetings
Weekly Trove Team Meeting
We have weekly team meetings on Wednesdays at 18:00 UTC in #openstack-meeting-alt
Want to add an agenda item? Please append your item to the upcoming weekly agenda while keeping in mind:
Guidelines for Writing Clear Agenda Items
An agenda item should have a clearly defined objective.
- [owner/author/interested-party] Good: Review #xxxxx has comments on foobar.py from multiple folks and there seems to be a lack of consensus on how to solve problem ‘y’. Let’s quickly rehash the merits of both approaches in 2-5 minutes and call for a vote. Goal: choose an approach and move forward on implementation.
- Bad: Discuss blueprint ‘xyz’
- Bad: Revisit blueprint ‘abc’ that we talked about last week to get answers on remaining disagreements.
When referring to previous conversations or competing viewpoints, be sure to summarize them.
Please make sure to include your own name in the first line of the agenda item, or the name of the person who will be presenting the subject/leading the discussion.
Trove Meeting, July 29, 2015
- SlickNik out on vacation July 29, 30, 31. cp16net will chair the meeting.
- [cp16net] Public voting for Tokyo Summit presentations is live through July 30 at 11:59pm PT.
- How much cluster can you muster?
- An introduction to "Database-as-a-Service" and OpenStack Trove
- Managing multiple database technologies with Trove
- To use DBaaS with Trove or to build your own, that is the question!
- DBaaS: #1 value added service for every Cloud Service Provider
- Trove on Containers – Live and without a net!
- Operating Trove in Production
- OpenStack Trove -- Hands on the OpenStack Database Service
- OpenStack Trove -- Building Databases on OpenStack
- Happy, Happy, Trove Trove.
- The cloud-enabled DBA of the 21st century
- Multi-AZ HA of Trove DB Instances with DRBD
- [cp16net] Datastore registration spec open questions
- We talked a little about this in the channel but want to bring this around to close on it.
- Questions we need answered to move on this spec.
- Should the api be simple CRUD operations on each object? (i.e. CRUD on datastores and versions separate) or make the API simplified where we really only care about the version when we update the image on an existing version or create a new version?
[cp16net] thoughts here on datastore registration spec
- the api should be modeled around the objects so that it makes sense in a restful way
- if we need a way to make things even easier like this helper that does multiple calls from a single command this might call for a new api call
- calling multiple api call from a single cmd gets the job done but seems wrong