Jump to: navigation, search

Difference between revisions of "Trove/MeetingAgendaHistory"

m (Trove Weekly Meeting Agenda History (2015))
m (Trove Weekly Meeting Agenda History (2015))
Line 160: Line 160:
** https://review.openstack.org/#/c/186357/
** https://review.openstack.org/#/c/186357/
** http://paste.openstack.org/raw/260020/
** http://paste.openstack.org/raw/260020/
== Trove Meeting, June 10, 2015 ==
* [SlickNik] Trove pulse update:
** https://etherpad.openstack.org/p/trove-pulse-update
* [SlickNik] Open Horizon Reviews.
** https://etherpad.openstack.org/p/trove-reviews-in-horizon
= Trove Weekly Meeting Agenda History (2014) =  
= Trove Weekly Meeting Agenda History (2014) =  

Revision as of 09:10, 17 June 2015


Trove Weekly Meeting Agenda History (2015)

Agenda for Jan 28th

  • Review #147908: Try to gain some consensus on how to resolve the issues itemized in final review comment.

Agenda for Jan 21st

  • Review #131610 : Security concerns, continued from the previous meeting + general review

Agenda for Feb 4th

  • Meeting canceled due to mid-cycle in Seattle

Agenda for February 18 2015

Agenda for February 25 2015

  • Trove pulse update:
  • [amrith] Need reviewers for 157140 [1]
    • Would like to have people look at this and consider it for merging quickly as there are other patch sets that will be impacted by it, especially the one reorganizing the guestagent code, anything that wants to add a new datastore, etc.,
    • There have been some comments (Simon, Ashleigh, Sushil) that I've tried to address in a reply but I would like some positive (or negative) reviews. Ok, I'd like some positive reviews ;)
  • [doug] Discuss 147908 [2]
    • There are a couple of options for how to proceed on this change and it would be good to get it into Kilo-3.
  • [schang] Discuss 136918 [3]
    • Discuss the comment thread at point #3 under the Guest Agent section. Need to decide what to do with the common code.
  • [amrith] Trove Liberty Mid Cycle Sprint -- Initial planning
  • [sushilkm] Needed reviewers for Vertica work
    • Looking forward for people to look at the Vertica work, the spec, trove-integration and trove patches.
    • The list of patchsets for the work is as follows:
  1. trove-specs: https://review.openstack.org/151126
  2. trove-integration: https://review.openstack.org/156149
  3. trove: https://review.openstack.org/156486

Agenda for March 4 2015

Trove Meeting, March 11, 2015

Trove Meeting, March 18, 2015

Trove Meeting, March 25, 2015

Trove Meeting, April 1, 2015

Trove Meeting, April 8, 2015

Trove Meeting, April 15, 2015 CANCELED

Trove Meeting, April 22, 2015

Trove Meeting, April 29, 2015 CANCELED

Trove Meeting, May 6, 2015

  • [SlickNik] Trove pulse update:
  • [schang]
    • We need to discuss this patchset, vote for an implementation option, and move forward: https://review.openstack.org/#/c/164640/9
    • Option 1: Define a default usage_timeout setting at the global level, the setting is optional at the datastore level, used only for the purpose of overriding the global default value.
    • Option 2: Define a mandatory usage_timeout option for each datastore.
    • These two options are mutually exclusive, meaning if we've already defined the option at the global level, and if the datastore is OK with the default value, it shouldn't be mandatory to re-specify the same default value at the datastore level.
    • The current patchset is implementing BOTH option 1 and 2.

Trove Meeting, May 27, 2015

  • [SlickNik] Trove pulse update:
  • [amrith] Do we need all these new hacking rules?
    • Changes have been proposed for inclusion of the following hacking rules [copied from commit message without validation]. E128, E265, E713, H238, E111, E122, E123, E128, E251, E265, E713, H105, H306, H404. (four changes, 3 in trove, one in trove-client)
    • When some hacking rule changes were proposed the last time (https://review.openstack.org/#/c/104616/ for example) the discussion at the Trove meeting was two-fold. First, that we didn't want to add all of these new hacking rules as they had limited upside. The second was that we'd consider reviewing them as a group before accepting changes. I'd like the group to consider all of these changes before we all spend time reviewing them. I would also like to have the ones for trove consolidated into one change to reduce the merge issues.
    • Personally, I find many of these hacking rules to have minimal benefit (if any). But I would rather we discuss them as a group before we all spend cycles reviewing them and then deciding (correctly) not to incorporate them as we have done in the past.
  • [amrith] Setting trove meeting agenda through git?
    • I saw this email on the ML this morning [4]
    • Does this change anything for us?
  • [peterstac] Switching blueprint ownership/details
  • [vkmc] Trove production deploy. Security concerns and how are we going to tackle those.
    • During the design sessions we talked about the security concern wrt RabbitMQ and the Trove instances living in public tenants.

There are several solutions proposed. Do we have a preference among those?

  • [vkmc] Trove multitenancy.
    • Has this came up in the past? What is the Trove community stand on that? Is it in our future plans?

Trove Meeting, June 3, 2015

Trove Meeting, June 10, 2015

Trove Weekly Meeting Agenda History (2014)

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 canceled

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

Agenda for Aug 13

Agenda for Aug 27

Agenda for Sep 3

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

Agenda for Sep 17

Agenda for Sep 24

Agenda for Oct 8

Agenda for Oct 15th

  • Discuss the timing of trove-guestagent refactoring. This is a big change and it would help to reduce rebasing if this was fast tracked or put on hold until other patches land. (rmyers)

Agenda for Oct 29th

  • [denis_makogon]
    • https://review.openstack.org/#/c/102838/ - During bug discussion (using report comments) was made unformal decision to mark all running backups as FAILED if instance is being deleted. But this checkin was marked with -2 from Auston (for more info see checkin comments). I'd like to discuss it and find suitable way for all of us.
    • https://review.openstack.org/#/c/130519/ - As we are all know that incremental backup can silently be executed as full backup because there's no incremental strategy for given backup strategy. This fix aims to fix it. But Amrith keep voting with -1 because he thinks that fix can be shorter. More info you can find out checkin comments. My idea is to have common validation method that executes specific logic depending on operation type. So, i'd like to hear concrete feedback from other contributors and find suitable way to fix it.
    • https://gist.github.com/denismakogon/15561df6dc5ddc60ba74 - We need to find proper way to handle cluster extension procedure using CLI. Also, as it was discussed, once clustering is merged we might proceed with changing existing python-troveclient framework (for more information see GIST).
  • [amrith]
    • Since the meeting next monday (BP meeting) will likely be preempted by the summit in Paris, I'd like to get some focus on a blueprint to allow users to retrieve guest log files. Please review https://review.openstack.org/#/c/131610/. I have re-written this specification and (with her permission) listed Iccha as the mentor of the person who will be implementing this.

Agenda for Nov 19th

  • Looking for reviews to oslo-incubator changes
    • 129292, Obsolete oslo-incubator modules - unused modules
    • 129294, Obsolete oslo-incubator modules - timeutils
    • 129714, Obsolete oslo-incubator modules - gettextutils (now oslo.i18n)
    • 129664, Obsolete oslo-incubator modules - network_utils (now netutils)
    • 129654, Obsolete oslo-incubator modules - excutils
    • 129295, Obsolete oslo-incubator modules - lockutils
    • 129663, Obsolete oslo-incubator modules - strutils
    • 129378, Obsolete oslo-incubator modules - importutils
    • 129668, Obsolete oslo-incubator modules - jsonutils (now oslo.serialization)
    • 133068, Obsolete oslo-incubator modules - wsgi
    • 133051, Obsolete oslo-incubator modules - exception
  • Better documentation for Image building
    • Goal: This was identified as an area of confusion in the summit. Identify what the next steps here are and establish a timeline for fixing this.
  • Trove Mid Cycle Sprint in Seattle, WA
  • Trove Cross Project Liasons

Agenda for Nov 26th

  • Dates for Trove Kilo Mid-Cycle sprint
  • Trove BP meeting -- to bp or not to bp?

Agenda for Dec 3rd

  • [amrith] Discuss merge order for various OSLO related patches
  • [amrith] Discuss status of moving guest agent to its own repository patch set

Trove Blueprint Meeting Agenda History (2014)

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:


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

Agenda for Jul 14

Agenda for Jul 21

Agenda for Jul 28

Aug 18 Meeting Canceled

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

Agenda for Aug 25

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

Sep 1 Meeting Canceled

  • Labor Day, so most folks are out

Agenda for Sep 8

Agenda for Sep 15

Agenda for Sep 22

Agenda for Oct 20

Agenda for Oct 22nd

Agenda for Oct 27

Agenda for Nov 3

Agenda for Nov 5

Meeting canceled

Agenda for Nov 12

Meeting canceled

Agenda for Nov 17


  • Example Snippet Generator - Tim Simpson


Agenda for Nov. 24

  • [flaper87, sgotliv, amrith] Switch Trove to use OSLO Messaging [5]
    • Since a spec in trove-specs is required for all projects related to blueprints that are intended for merge in Kilo, this spec has been submitted for review based on a document that was already in the old wiki format. A procedural approval similar to the ones granted to other specs [flavor id's and datastore versions] is requested for this.
  • [iccha, amrith] Allow users to retrieve guest log files [6]
  • [dougshelley66] Add instance name as parameter to various CLI commands [7]