Jump to: navigation, search

Difference between revisions of "Meetings/TroveMeeting"

m (Agenda for Sep 10)
m (Agenda for Sep 10)
Line 29: Line 29:
 
** Related IRC discussions: http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2014-08-27.log
 
** Related IRC discussions: http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2014-08-27.log
  
* trove-specs is on its way for Kilo
+
* trove-specs is underway for Kilo ("slicknik")
 
** https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle
 
** https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle
 
** All blueprints going forward (for Kilo) must include a spec proposed to the trove-specs repo.
 
** All blueprints going forward (for Kilo) must include a spec proposed to the trove-specs repo.

Revision as of 17:49, 10 September 2014

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.

  • 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.

Agenda for Sep 10

  • Clusters Migration and Downgrades (schang)
    • The new v32 clusters migration script creates a foreign key constraint between the clusters table and the database_versions table, but it's downgrade script do not cleanup the table and the foreign key constraint, causing the v16 downgrade to fail on dropping the database_versions table.
    • To ensure error free downgrades moving forward, we have these options:
      • All migration scripts' downgrade needs to cleanup tables and foreign key constraints:
        • Nobody currently do downgrade migrations on a production system. Shouldn't downgrade's purpose be allowing devs to perform hard resets on their test databases? If test data preservation is needed, the dev should manually backup and restore the table.
        • Establish version points at which downgrade is not permitted. e.g. Downgrade v32 -> v25 is allowed, but you can't downgrade from latest to anything pre v25.
      • Only test the upgrade path in the test script.
      • Remove all downgrade routines and don't support downgrade migrations at all.
    • Action Item: Discuss the above options and decide on an approach.
    • Review: https://review.openstack.org/#/c/117291/
    • Error log: http://logs.openstack.org/91/117291/3/check/gate-trove-python27/6074fb4/console.html.gz
    • Related IRC discussions: http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2014-08-27.log



Meeting Chat Logs: http://eavesdrop.openstack.org/meetings/trove/2014/
Meeting Agenda History: https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory#Trove_Weekly_Meeting_Agenda_History

Note: BP Meetings now have their own wiki page at: https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting