Jump to: navigation, search

Difference between revisions of "Meetings/TroveMeeting"

(Trove Meeting, Oct 7, 2015)
(Trove Meeting, Oct 7, 2015)
Line 18: Line 18:
  
 
== Trove Meeting, Oct 7, 2015 ==
 
== Trove Meeting, Oct 7, 2015 ==
* Trove community and containers (mlowery)
+
* Trove community and containers [mlowery]
 
** Is there any plan to adopt containers (e.g. Docker) in any way in Trove within the community?
 
** Is there any plan to adopt containers (e.g. Docker) in any way in Trove within the community?
 
*** Example: Put the guest agent in a container. Upgrade it by replacing the container. (You no longer have to care about the current state of the guest (the existing bits)--just replace it.) The same approach could be taken with the datastore itself: put it in a container.
 
*** Example: Put the guest agent in a container. Upgrade it by replacing the container. (You no longer have to care about the current state of the guest (the existing bits)--just replace it.) The same approach could be taken with the datastore itself: put it in a container.
Line 24: Line 24:
 
*** Example: Kubernetes handles scheduling, updating, and scaling (including auto-healing). Some of these are Nova/Heat-like. Some of these (like auto-healing) don't exist. Is auto-healing in Trove's charter? Could Kubernetes or Magnum be a pluggable "orchestration driver" within Trove?
 
*** Example: Kubernetes handles scheduling, updating, and scaling (including auto-healing). Some of these are Nova/Heat-like. Some of these (like auto-healing) don't exist. Is auto-healing in Trove's charter? Could Kubernetes or Magnum be a pluggable "orchestration driver" within Trove?
  
* Refactor of Manager class (peterstac)
+
* Refactor of Manager class [peterstac]
** We're at the beginning of the Mitaka cycle.  If we want to refactor the Manager class structure (and there are many good reasons why we should) we need to do it at the beginning of this cycle.  As such, I'd like to get some quick feedback on the proposed spec to expedite the process. https://review.openstack.org/#/c/231572/
+
** We have previously discussed the merits of refactoring the Manager class structure (and there are many good reasons why we should), however the consensus has been that it would need to be done at the beginning of a cycle.  We're now at the beginning of a (Mitaka) cycle :).  As such, I'd like to draw some attention to the spec and make sure that the proposed solution has no glaring issues.
 +
*** Blueprint: https://blueprints.launchpad.net/trove/+spec/datastore-manager-refactor
 +
*** Spec: https://review.openstack.org/#/c/231572
 +
** The refactor also addresses the issue of the instance state changing erroneously.  I have tested the proposed solution internally and it does fix the issue.
 +
*** See https://bugs.launchpad.net/trove/+bug/1482795
 +
*** See https://bugs.launchpad.net/trove/+bug/1487233
  
 
<br/>
 
<br/>

Revision as of 16:36, 6 October 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, Oct 7, 2015

  • Trove community and containers [mlowery]
    • Is there any plan to adopt containers (e.g. Docker) in any way in Trove within the community?
      • Example: Put the guest agent in a container. Upgrade it by replacing the container. (You no longer have to care about the current state of the guest (the existing bits)--just replace it.) The same approach could be taken with the datastore itself: put it in a container.
    • Is there any plan to adopt container orchestration (e.g. Kubernetes) in any way in Trove within the community?
      • Example: Kubernetes handles scheduling, updating, and scaling (including auto-healing). Some of these are Nova/Heat-like. Some of these (like auto-healing) don't exist. Is auto-healing in Trove's charter? Could Kubernetes or Magnum be a pluggable "orchestration driver" within Trove?


Meeting Agenda History
Meeting Chat Logs