Jump to: navigation, search

Trove/MeetingAgendaHistory

< Trove
Revision as of 02:15, 9 September 2014 by Slicknik (talk | contribs) (Trove Weekly Meeting Agenda History)

Trove Weekly Meeting Agenda History

Agenda for Mar. 19

Agenda for Mar. 26

Agenda for Apr. 2

  • Icehouse RC1 cut and Juno branch open
  • ATL Dev Summit topics
  • Open discussion

Agenda for Apr. 9

Agenda for Apr. 16

Agenda for Apr. 23

  • Juno Mid-cycle Meetup - discuss venue/timing proposal and confirm

Agenda for Apr. 30

  • Establish policy for disk image builder elements for datastores [mat-lowery]
    • Do we require elements for both Ubuntu and Fedora when a Gerrit change introduces a new datastore or version?
      • Cassandra and Couchbase are examples of datastores that don't currently have Fedora elements. https://review.openstack.org/77461 and https://review.openstack.org/79413 are examples of Gerrit changes that have been -1ed because of lack of Fedora elements.
      • Isn't one working element better than none? If both are required, is that inviting lower quality on the other element the user is required to code but never uses?
      • Are Fedora elements tested in an automated way as the Ubuntu elements are? Reasoning: Yes they were submitted with the Gerrit change, but do they work?
      • Is the policy that Trove requires both Fedora and Ubuntu support for each manager on day one? There is already a lack of parity across datastore managers--not all can do backup and restore (but ultimately I assume they will). Why can't Trove take distro support piecemeal just like it does the datastore operations?
      • mat-lowery (talk) Wed Apr 30 19:17:28 UTC 2014
        • Result: <SlickNik> Let's table this for now.
    • What about Package Install vs. Tarball Install vs. Source Install? Is there a requirement on how the bits are laid down?
      • If packages are required, what are the acceptable sources? (Example: Redis currently uses a PPA.)
      • Does the decision here have repercussions on datastore upgrades?
      • mat-lowery (talk) Wed Apr 30 19:17:28 UTC 2014
        • Result: <SlickNik> So allow [PPAs]. But let's make a best effort to follow this order: distro package, project maintainer PPA, some random PPA.
  • Open Items
    • Clarification on commit message style guidelines (slicknik): We've been having a lot of -1 reviews on commit message style and I wanted to clarify some of this so that we can reduce review churn caused by this. Goal: Have a clear understanding on when a commit message should be -1'ed.

Agenda for May 7

  • How do Gerrit changes get approved? [mat-lowery]
    • Goal: To clarify the Gerrit change approval process used by Trove core (for the benefit of core and non-core).
      • Core potentially benefits by establishing a process that all core follows (and possibly swap best practices).
        • What if all core used a prioritized queue such as ReviewDay? If you're not using a prioritized queue, how do you prevent starvation?
      • Non-core potentially benefits by making the process transparent and setting expectations.
        • "Hey core, please review <change>" is inefficient and unfair. The priority (such as that calculated by ReviewDay) should be the sole indicator of review/approval priority.
    • Goal: To reduce the time from submittal to approval and prevent Gerrit change starvation.
      • My first-ever Trove submittal is nearly three months old. Why is that?
      • Establish Gerrit "etiquette."
        • No leaving -1s and then disappearing. A reviewer that leaves a -1 has an obligation to respond to follow up questions.
        • No leaving -1s for nice-to-haves. That's what 0 is for.
        • No leaving -1s for questions about why something was done. Again, use a 0.
        • No leaving -1s for something minor when there are five +1s.
        • Leaving a -1 has the potential to cause the author to "reset the counter" (because he has to submit a new revision) on age-influenced priorities (such as ReviewDay). Think hard before you leave that -1.
    • More details on the mailing list.
  • Meetings cancelled next week since most folks will be at the ATL summit [slicknik]

May 14 meeting cancelled

Agenda for May 21

Agenda for May 28

Agenda for Jun 4

Agenda for Jun 11

Agenda for Jun 25

  • Integration-tests update (SlickNik)
  • "Vertica Datastore patch review" why no reviews ? (SnowDust)

Agenda for July 2

Agenda for July 9

  • Scrub / Update Docs (SlickNik): The following need to be scrubbed. I'd like to get a few volunteers to take a look at each one of these, identify areas where they are deficient, and help fix them. Areas to update are tracked at https://etherpad.openstack.org/p/trove-doc-items.
    • Developer Docs
    • Deployment Guide
    • API Doc
    • Config Options help strings
    • Manual Trove Install Doc

Agenda for July 16

Agenda for July 23

Agenda for Aug 06

Aug 13 Meeting

Aug 27 Meeting

Sep 3 Meeting

Trove Blueprint Meeting Agenda History

For those interested, we have blueprint meetings in #openstack-trove weekly, Mondays at 18:00 UTC. Feel free to add items in the agenda below.

Agenda for Mar. 31

Networking related blueprints:

Others:

Agenda for Apr. 7

Agenda for Apr. 14

Agenda for Apr. 21

Agenda for April 28

Agenda for May 5

Meeting Cancelled May 12

Agenda for May 19

  • Trove client for cross-region-backup [esmute]
    • https://blueprints.launchpad.net/trove/+spec/cross-region-backup-availability
    • amcrn (talk) 18:24, 19 May 2014 (UTC): Meeting Minutes: this was originally scheduled due to concerns with introducing a new field called "region". at the time, there was no consensus as to whether namespacing should be used (arn-style), etc. during the summit, we reached a consensus (in the clustering talks) that a "region" field is the way to go, and therefore there's no action items here.
  • Add visibility filter to datastores [iccha]
    • https://blueprints.launchpad.net/trove/+spec/datastore-visibility
    • amcrn (talk) 18:24, 19 May 2014 (UTC): Meeting Minutes: consensus is that if is_active is 0, then only if the tenant-id is in a whitelist (new table?) will they be able to use and see the datastore-version. this is more aligned with how glance deals with images vs. what's proposed in the orginal spec here (a simple admin-only).
  • Database log files manipulations [denis_makogon]
    • https://blueprints.launchpad.net/trove/+spec/dbinstance-log
    • amcrn (talk) 18:54, 19 May 2014 (UTC): Meeting Minutes: the following modifications are required for approval (1) adding posix created/modified timestamp fields on the response so that a user knows when the log was last touched and/or rotated (2) use configuration-groups for configuration parameters (vs. introducing the mapping in the code) (3) fix a few bugs in the blueprint, including inconsistent usage of underscore vs. hyphen in naming, and datastore_log_files should be an array.


amcrn (talk) 19:04, 19 May 2014 (UTC): the items below by boden are being tabled at the moment (pending confirmation of sponsorship and a discussion surrounding the precedent this sets). amrith to send an email to boden to sync up.

Agenda for Jun 2

slicknik (talk) 21:22, 2 June 2014 (UTC) There were concerns around whether keystone trusts is fully done yet, and what other OpenStack projects are going to use this. We had a vote, and the unanimous result was to wait and watch for now.

slicknik (talk) 21:22, 2 June 2014 (UTC) Approved. There was one small concern about backward-compat with the GET /flavors api call which should be addressed.

slicknik (talk) 21:22, 2 June 2014 (UTC) Needs more detail as to what phase 2 will actually entail. Denis to update the bp with more details.

slicknik (talk) 21:22, 2 June 2014 (UTC) Approved

slicknik (talk) 21:22, 2 June 2014 (UTC) Approved

slicknik (talk) 21:22, 2 June 2014 (UTC) Needs more information regarding. Boden to update the BP.

slicknik (talk) 21:22, 2 June 2014 (UTC) Ran out of time and didn't get to this. Tabled for a later meeting.

Agenda for Jun 23

Jul 14 Meeting


Jul 21 Meeting


Jul 28 Meeting

Aug 18 Meeting CANCELED

  • Most trove folks traveling for Trove Day + Midcycle event in Cambridge, MA

Aug 25 Meeting

  • [amrith]
    • What do we do about SUSE? There are bugs coming in at a steady clip fixing little things that don't work in SUSE but in some cases, no test cases are being proposed nor is there a clear plan to get SUSE on the supported platform list. How do we want to proceed? I raise this question because I don't want to use the review process as the place to discuss on a patch-by-patch basis whether a certain code change should be considered or not; rather raise it and address it as a larger issue of how we get to a supported SUSE platform including testing on an ongoing basis, etc.,