Revision as of 16:11, 27 May 2015

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, May 27, 2015

• [SlickNik] Trove pulse update:
  • https://etherpad.openstack.org/p/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 [1]
  • Does this change anything for us?
• [peterstac] Switching blueprint ownership/details
  • There's an existing blueprint for Redis backup/restore https://blueprints.launchpad.net/trove/+spec/redis-backup-restore
  • A new spec was created for it https://review.openstack.org/#/c/182910/
  • The blueprint wasn't changed to point to the new spec (mainly because I couldn't edit it :{ )
  • Now a review has appeared for an implementation of Redis backup/restore https://review.openstack.org/#/c/185892/
  • Question: What is (should be?) our policy on taking over work that has a bp, but hasn't been started/completed?
• [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?

Meeting Agenda History
Meeting Chat Logs