Difference between revisions of "Trove/MeetingAgendaHistory"
< Trove
(→Agenda for Apr. 21) |
|||
| Line 162: | Line 162: | ||
** https://blueprints.launchpad.net/trove/+spec/read-only-user | ** https://blueprints.launchpad.net/trove/+spec/read-only-user | ||
| − | + | == Agenda for April 28 == | |
* Percona support [mattgriffin]: | * Percona support [mattgriffin]: | ||
** https://blueprints.launchpad.net/trove/+spec/support-percona-xtrabackup-2.2 | ** https://blueprints.launchpad.net/trove/+spec/support-percona-xtrabackup-2.2 | ||
Revision as of 10:01, 1 May 2014
Trove Weekly Meeting Agenda History
Agenda for Mar. 19
- https://blueprints.launchpad.net/trove/+spec/refactoring-datastore-options-in-cfg
- Moving away from mockito (https://blueprints.launchpad.net/trove/+spec/remove-mockito)
- Clustering API Container vs Joins approach.
Agenda for Mar. 26
- Summit sessions [hub_cap]
- Data Store abstraction start/stop/status/control [amrith]
- Icehouse, RC1, and juno
Agenda for Apr. 2
- Icehouse RC1 cut and Juno branch open
- ATL Dev Summit topics
- Open discussion
Agenda for Apr. 9
- Refactoring backup/restore strategies [denis_makogon]
- Moving the docs [grapex]
- Design Summit Session Proposals
Agenda for Apr. 16
- Discuss the expectations of an agenda item for the weekly meeting [core/amcrn]
- Goal: Explain what is expected of an agenda item to guarantee the conversation stays on topic and is headed toward meeting a goal or resolving an issue.
- amcrn (talk) 07:13, 17 April 2014 (UTC):
- Result: majority vote agrees that each agenda item should have an objective and be goal-oriented.
- Solution: as a result, guidelines for agenda items have been added to the top of this wiki and the core team has agreed to shepherd folks for the next few weeks on how to fine tune their agenda items.
- Next Steps: enforce guidelines/rules.
- Datastore and Datastore Version Concat in Trove Horizon Dashboard [michael-yu]
- Question to Answer: Should there be two columns in list-view, and two dropdowns in launch-view, for datastore and datastore-version respectively? Or should they be concatenated into one?
- See the ongoing conversation at https://review.openstack.org/#/c/75269/14/openstack_dashboard/dashboards/project/databases/tables.py and https://review.openstack.org/#/c/75269/14/openstack_dashboard/dashboards/project/databases/workflows/create_instance.py .
- amcrn (talk) 07:13, 17 April 2014 (UTC):
- Result: majority vote agrees that datastore-type and datastore-version should be consolidated into one dropdown for the launch-instance workflow and one column for list-view. long-term, many believe this to be a hint/indication that datastore-type and datastore-version should be combined into a single field for the v2 api, but this is yet to be seen.
- Next Steps: michael-yu updating his horizon patch-set (https://review.openstack.org/#/c/75269/) to be single dropdown/column and amcrn updating trove-integration to default to a naming scheme that plays well with this model (https://review.openstack.org/#/c/88119/)
- Perform integration testing for the heat based instances [Shivamshukla]
- https://blueprints.launchpad.net/openstack/?searchtext=test-heat-based-instance-workflow
- What could be the way to test instance workflow through heat.
- amcrn (talk) 07:39, 17 April 2014 (UTC)
- Summary: some tests for a heat-based workflow (https://review.openstack.org/#/c/66499/) require changing trove-taskmanager conf values, which then require a restart of the trove-taskmanager. the problem with requiring a restart is that it makes the naive assumption that it's not a remote system.
- Solution: add a test.conf flag that indicates whether non-remote tests should be run (i.e. tests that require the restart of trove-taskmanager). long-term, a majority agree that a separate heat gate should be birthed.
- Next Steps: shivamshukla to update the patch-set to include the test.conf flag mentioned above.
- Neutron Support, SecGroup Management, and Networking [annashen, denis_makogon]
- https://blueprints.launchpad.net/trove/+spec/neutron-support + https://blueprints.launchpad.net/trove/+spec/secgroup-mgmt-via-neutron + https://blueprints.launchpad.net/trove/+spec/network-manager-spec
- amcrn (talk) 07:57, 17 April 2014 (UTC):
- Result: annashen will unilaterally/single-handedly own the blueprint + implementation for supporting neutron in trove. the three related blueprints (https://blueprints.launchpad.net/trove/+spec/neutron-support + https://blueprints.launchpad.net/trove/+spec/secgroup-mgmt-via-neutron + https://blueprints.launchpad.net/trove/+spec/network-manager-spec) are to be merged into one (the final destination being https://blueprints.launchpad.net/trove/+spec/neutron-support). a majority agrees that this consolidated blueprint needs to clearly articulate the requirements, beyond just stating "support running neutron instead of nova-network".
- Next Steps: annashen to deliver unified blueprint and implementation.
- Refactoring backup/restore strategies (re-visiting from previous meeting) [denis_makogon]
- https://launchpad.net/bugs/1287684
- amcrn (talk) 07:57, 17 April 2014 (UTC)
- Result: Ran out of time, was not discussed in the meeting.
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.
- Do we require elements for both Ubuntu and Fedora when a Gerrit change introduces a new datastore or version?
- 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.
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
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:
- Network attribute management [denis_makogon]
- Neutron Support for Trove [annashen]
- Trove Managed Instances on Private Network [juice]
Others:
- Point in time recovery [denis_makogon]
- Data volume snapshot [denis_makogon]
- Instance metadata [imsplitbit]
Agenda for Apr. 7
- Point in time recovery [denis_makogon]
- Data volume snapshot [denis_makogon]
- Networking [denis_makogon]
- Cross-region backups [esmute]
- Descriptions to Datastore Configuration Group Parameters [cp16net]
- Categorize the trove-manage commands [cp16net]
- Neutron Network Support [annashen]
- Trove-Managed Instances [juice]
Agenda for Apr. 14
- Datastore Capabilities [k-pom]
- Descriptions to Datastore Configuration Group Parameters [cp16net]
- Categorize the trove-manage commands [cp16net]
- Point in time recovery [denis_makogon]
- Data volume snapshot [denis_makogon]
- Networking [denis_makogon]
- Neutron [annashen]
- Move the Trove Guest Agent to its own module [robertmyers]
- Unify common code in guest agent configurations [amrith and snowdust]
- Adding datastore and version to the backup API [robertmyers]
Agenda for Apr. 21
- Unify common code in guest agent configurations [amrith and snowdust]
- Adding datastore and version to the backup API [robertmyers]
- Move the Trove Guest Agent to its own module [robertmyers]
- Database log files manipulations [denis_makogon]
- Resource management driver [denis_makogon]
- Add backup and restore support for single instance couchbase [michael-yu]
- Populate endpoint URLs from Keystone service catalog [esmute]
- Enable specification of Cinder Volume Types
- Add ability to create read-only users via the users API
Agenda for April 28
- Percona support [mattgriffin]:
- Support for Vertica [yogeshmehra]:
- Resource management driver [denis_makogon]
- Managed Instances [juice]
- List all datastore types and versions by a single API call [nehav]
