OpenStack - User contributions [en]

Meetings/TroveMeeting

2016-03-29T14:01:34Z

Doug Shelley:

= 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, March 30, 2016 ==

* Action items from last week's meeting
** [all] If you have a patch set that you intend to resume work on, please put an update in it to that effect so we don't go abandon it under you ...
** [all] if any of the abandoned patches looks like something you would like to pick up feel free
** cp16net reply to trove-dashboard ML question for RC2
** [all] please review changes [ https://review.openstack.org/#/c/262289/], [ https://review.openstack.org/#/c/262287/], and link [ http://openstack.markmail.org/thread/jepcqu335mrb5c7l] in agenda and update the reviews
** flaper87 to WF+1 the patches in question [ https://review.openstack.org/#/c/262289/] and [ https://review.openstack.org/#/c/262287/] [DONE]
* Trove pulse update
** http://bit.ly/1VQyg00 [http://bit.ly/1VQyg00]
* Announcements
** [http://releases.openstack.org/newton/schedule.html Newton release schedule has been published ]
*** Some things I've learned from the Mitaka cycle
**** The schedule is known so far in advance that it is prudent to plan for it
**** The dates for things that are listed as "Final" are in fact final and not subject to FFE's
***** If we want to push any code into OSLO, R-6 is a hard deadline.
***** R-5, is the '''hard''' freeze for the python-troveclient. We '''must''' get all new functionality we need in the client into a version by that date or it won't be available for the release.
***** R-5 is the '''target date''' by which all new functionality should be in, you need to request FFE's for anything that does not merge by that date
***** R-3 is the RC1 '''target date''', not a hard date. In the Mitaka cycle, I mistakenly believed that R-3 is a hard RC1 date. My mistake.
** [https://review.openstack.org/#/c/164035/ Getting rid of eventlet and replacing it with something else]

* Ongoing review of projects. At the mid-cycle in Raleigh, one of the action items that we took away was that we should start tracking and monitoring all projects under way to completion through the release cycle. I'm going to start this up with the projects that we know are under way, and begin to highlight them so that people can focus time on reviewing them.
** [pmackinn] [https://review.openstack.org/#/c/295274/ Separate trove image build project based on libguestfs tools]
** [tellesnóbrega/vkmc] [https://review.openstack.org/#/c/256057/ Implementing CEPH as a backend for backups]
** [sonali/vkmc] [https://review.openstack.org/#/c/263980/ Configuration Groups for Couchdb]
** [johnma] [https://review.openstack.org/#/c/255437/ Enable CouchDB replication in Trove]
** [amrith] [https://review.openstack.org/#/c/256079/ Add support for hbase in Trove]
** [peterstac] [https://blueprints.launchpad.net/trove/+spec/replication-affinity Affinity for replication sets]
** [peterstac] Affinity for clusters - BP coming
** [petmal] [https://blueprints.launchpad.net/trove/+spec/couchbase-cluster-support Couchbase clusters]
** [vgnbkr] Guest instance upgrade - BP coming
** [petmal] [https://blueprints.launchpad.net/trove/+spec/postgresql-incremental-backup PostgreSQL incremental backup/restore]
** [petmal] [https://blueprints.launchpad.net/trove/+spec/replication-affinity PostgreSQL replication]
** [mvandijk] [https://blueprints.launchpad.net/trove/+spec/associate-volume-type-datastore Associate volume-type with datastore]
** [vgnbkr] [https://review.openstack.org/#/c/294213/ Multi-Region Support]
* Summit planning
** [https://etherpad.openstack.org/p/trove-newton-proposed-sessions Propose sessions for the summit]
** [http://markmail.org/message/avbqqzwhog36tme2 Conference room allocations announced] (Trove: 3fb, 6wr, cm:half)
** [http://openstack.markmail.org/thread/yeg57r5yyddveoka Austin Design Summit track layout] The Trove sessions are as follows, please mark your calendars.
*** (WR1) Tuesday 0950 to 1030
*** (WR2) Wednesday 1350 to 1430
*** (WR3) Wednesday 1530 to 1610
*** (WR4) Thursday 1150 to 1230
*** (WR5) Thursday 1330 to 1410
*** (WR6) Thursday 1420 to 1500
*** (FB1) Wednesday 1720 to 1800
*** (FB2) Thursday 0950 to 1030
*** (FB3) Thursday 1100 to 1140
*** (CM) Friday 0900 to 1230.
* Planning for mid-cycle
** It seems like this is a long way off but it really isn't.
** I'd like to propose R-7, in the New York City area.
* Open Discussion

 
[https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory Meeting Agenda History]
 
[http://eavesdrop.openstack.org/meetings/trove/2016 Meeting Chat Logs]

==Running The Meeting==
* To start the meeting, use <code><nowiki>#startmeeting trove</nowiki></code>
* Then, publish the link to the agenda for the meeting (this page).
* Use <code><nowiki>#topic</nowiki></code> to mark each topic change.
* You can find the near-full list of Meetbot commands [https://wiki.debian.org/MeetBot here]. Instructions for voting (which can be useful for a quick show of hands) live [http://docs.openstack.org/infra/system-config/irc.html#voting here].
* During the meeting, don't forget to liberally use <code><nowiki>#info</nowiki></code>, <code><nowiki>#agreed</nowiki></code>, <code><nowiki>#action</nowiki></code> or <code><nowiki>#link</nowiki></code> to make sure the critical discussion points will be highlighted in the meeting log. Attendees can use these Meetbot keywords as well.
* To end the meeting, use <code><nowiki>#endmeeting</nowiki></code>

Meetings/TroveMeeting

2016-03-29T13:58:52Z

Doug Shelley:

= 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, March 30, 2016 ==

* Action items from last week's meeting
** [all] If you have a patch set that you intend to resume work on, please put an update in it to that effect so we don't go abandon it under you ...
** [all] if any of the abandoned patches looks like something you would like to pick up feel free
** cp16net reply to trove-dashboard ML question for RC2
** [all] please review changes [ https://review.openstack.org/#/c/262289/], [ https://review.openstack.org/#/c/262287/], and link [ http://openstack.markmail.org/thread/jepcqu335mrb5c7l] in agenda and update the reviews
** flaper87 to WF+1 the patches in question [ https://review.openstack.org/#/c/262289/] and [ https://review.openstack.org/#/c/262287/] [DONE]
* Trove pulse update
** http://bit.ly/1VQyg00 [http://bit.ly/1VQyg00]
* Announcements
** [http://releases.openstack.org/newton/schedule.html Newton release schedule has been published ]
*** Some things I've learned from the Mitaka cycle
**** The schedule is known so far in advance that it is prudent to plan for it
**** The dates for things that are listed as "Final" are in fact final and not subject to FFE's
***** If we want to push any code into OSLO, R-6 is a hard deadline.
***** R-5, is the '''hard''' freeze for the python-troveclient. We '''must''' get all new functionality we need in the client into a version by that date or it won't be available for the release.
***** R-5 is the '''target date''' by which all new functionality should be in, you need to request FFE's for anything that does not merge by that date
***** R-3 is the RC1 '''target date''', not a hard date. In the Mitaka cycle, I mistakenly believed that R-3 is a hard RC1 date. My mistake.
** [https://review.openstack.org/#/c/164035/ Getting rid of eventlet and replacing it with something else]

* Ongoing review of projects. At the mid-cycle in Raleigh, one of the action items that we took away was that we should start tracking and monitoring all projects under way to completion through the release cycle. I'm going to start this up with the projects that we know are under way, and begin to highlight them so that people can focus time on reviewing them.
** [pmackinn] [https://review.openstack.org/#/c/295274/ Separate trove image build project based on libguestfs tools]
** [tellesnóbrega/vkmc] [https://review.openstack.org/#/c/256057/ Implementing CEPH as a backend for backups]
** [sonali/vkmc] [https://review.openstack.org/#/c/263980/ Configuration Groups for Couchdb]
** [johnma] [https://review.openstack.org/#/c/255437/ Enable CouchDB replication in Trove]
** [amrith] [https://review.openstack.org/#/c/256079/ Add support for hbase in Trove]
** [peterstac] [https://blueprints.launchpad.net/trove/+spec/replication-affinity Affinity for replication sets]
** [vgnbkr] [https://review.openstack.org/#/c/294213/ Multi-Region Support]
* Summit planning
** [https://etherpad.openstack.org/p/trove-newton-proposed-sessions Propose sessions for the summit]
** [http://markmail.org/message/avbqqzwhog36tme2 Conference room allocations announced] (Trove: 3fb, 6wr, cm:half)
** [http://openstack.markmail.org/thread/yeg57r5yyddveoka Austin Design Summit track layout] The Trove sessions are as follows, please mark your calendars.
*** (WR1) Tuesday 0950 to 1030
*** (WR2) Wednesday 1350 to 1430
*** (WR3) Wednesday 1530 to 1610
*** (WR4) Thursday 1150 to 1230
*** (WR5) Thursday 1330 to 1410
*** (WR6) Thursday 1420 to 1500
*** (FB1) Wednesday 1720 to 1800
*** (FB2) Thursday 0950 to 1030
*** (FB3) Thursday 1100 to 1140
*** (CM) Friday 0900 to 1230.
* Planning for mid-cycle
** It seems like this is a long way off but it really isn't.
** I'd like to propose R-7, in the New York City area.
* Open Discussion

 
[https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory Meeting Agenda History]
 
[http://eavesdrop.openstack.org/meetings/trove/2016 Meeting Chat Logs]

==Running The Meeting==
* To start the meeting, use <code><nowiki>#startmeeting trove</nowiki></code>
* Then, publish the link to the agenda for the meeting (this page).
* Use <code><nowiki>#topic</nowiki></code> to mark each topic change.
* You can find the near-full list of Meetbot commands [https://wiki.debian.org/MeetBot here]. Instructions for voting (which can be useful for a quick show of hands) live [http://docs.openstack.org/infra/system-config/irc.html#voting here].
* During the meeting, don't forget to liberally use <code><nowiki>#info</nowiki></code>, <code><nowiki>#agreed</nowiki></code>, <code><nowiki>#action</nowiki></code> or <code><nowiki>#link</nowiki></code> to make sure the critical discussion points will be highlighted in the meeting log. Attendees can use these Meetbot keywords as well.
* To end the meeting, use <code><nowiki>#endmeeting</nowiki></code>

Meetings/TroveMeeting

2015-01-28T16:51:58Z

Doug Shelley:

Trove/JunoCycleMeetup

2014-08-15T15:32:18Z

Doug Shelley: Replaced content with " This page was a duplicate of https://wiki.openstack.org/w/index.php?title=Trove/JunoMidCycleMeetup"

This page was a duplicate of https://wiki.openstack.org/w/index.php?title=Trove/JunoMidCycleMeetup

Sprints

2014-08-15T15:14:12Z

Doug Shelley:

=== Future sprints ===

Here is a chronological list of future sprints. please keep it ordered and remove past ones.

{| border="1" cellpadding="4" cellspacing="4"
|- bgcolor=#eeeeee
| Date
| Location
| Theme
| More information at
|-
| July 2 - 4
| Paris, France
| Ceilometer/All projects
| [[Sprints/ParisJuno2014]]
|-
| July 7 - 9
| San Antonio, TX, USA
| Barbican
| TBD, [[Meetings/Barbican]]
|-
| July 9 - 11
| Bloomington, MN, USA
| Neutron
| [https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting]
|-
| July 9 - 11
| San Antonio, TX, USA
| Keystone
| [http://dolphm.com/openstack-keystone-hackathon-for-juno/]
|-
| July 14 - 18
| Darmstadt, Germany
| QA & Infra
| [[Qa_Infra_Meetup_2014]]
|-
| July 14 - 18
| Seattle, USA
| Security Group
| [https://etherpad.openstack.org/p/ossg-juno-meetup]
|-
| July 21 - July 25
| Raleigh, NC, USA
| TripleO (& Heat)
| [https://etherpad.openstack.org/p/juno-midcycle-meetup]
|-
| July 28 - Jul 30
| Beaverton, OR, USA
| Nova & Ironic
| [[Sprints/BeavertonJunoSprint]]
|-
| Aug 11 - Aug 15
| Fort Collins, CO
| Cinder
| [[https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014]]
|-
| Aug 18 - Aug 20
| Raleigh, NC, USA
| Heat
| [https://etherpad.openstack.org/p/heat-juno-midcycle-meetup]
|-
| Aug 20 - Aug 23
| Cambridge, MA, USA
| Trove
| [[Trove/JunoMidCycleMeetup|Link]]
|-
| July 24 - July 25
| Palo Alto, CA, USA
| Glance
| [[https://etherpad.openstack.org/p/glance-juno-mid-cycle-meeting]]
|}

Trove/JunoMidCycleMeetup

2014-08-15T15:07:43Z

Doug Shelley:

= Database Program (Trove) - Juno Mid-cycle Meetup =

== What ==

There will be a mid-cycle meetup for ATCs (Active Technical Contributors) to the OpenStack Database program in August, 2014.
The final schedule of topics will be determined by those that attend, shortly before the event.

Tesora [http://www.tesora.com] is helping organize this event.

== When ==

3 days, August 20-22, 2014

== Where ==

The MidCycle Meetup will be held at MIT (CSAIL), in Cambridge, MA.

The meetings will be in building 32 [http://whereis.mit.edu/?go=32]

== Event Details ==
On Tuesday, from 9AM to 5PM, Tesora is organizing an OpenStack Trove Day, a day of events about OpenStack with a focus on Trove. If you are attending the mid-cycle meetup, consider attending this event as well. Contact Amrith (amrith (at) tesora (dot) com, or amrith on IRC) or Doug (doug (at) tesora (dot) com, or dougshelley66 on IRC) for more details

{| class="wikitable"
|-
! Time !! Wed !! Thr !! Fri
|-
| 9-11 || Meets and greets || State of CI and Testing || OpenStack Integration (oslo, ceilometer, etc)
|-
| 11-1 || Show and tell - Juno Edition || Replication and Failover || Capabilities
|-
| 1-3 || Current state of blueprints || Clustering Next Steps || UI / Horizon update
|-
| 3-5 || Current state of Docs || Heat Update || Parking Lot
|}

=== Registration ===
* Please confirm your attendance at https://www.eventbrite.com/e/openstack-mid-cycle-meetup-tickets-11663001351

=== Key Signing Party ===

If there is interest, we will conduct a Key Signing Party
More details at: https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Trove_Icehouse_Sprint

=== Hotels ===
Hotels close to the event (closest on the top of the list).

Cambridge Marriott, 50 Broadway, Cambridge [http://www.marriott.com/hotels/travel/boscb-boston-marriott-cambridge/]

We have a block of rooms here at $259 per night. The advertised rates are much higher ($324). When booking be sure to ask for the "Tesora" event rate.

There are several other hotels in the neighborhood. If you get a much better deal, please update this page so others can benefit from it.

'''UPDATE: The block is for the mid-cycle meetup as well as people who are attending the Trove event sponsored by Tesora. They'll fill up fast, book quickly. Cambridge is expensive and other options are likely to be a lot more pricey.'''

=== Travel ===
* Recommended airport: BOS, Boston Logan International Airport, Boston, MA
* Alternate airport: PVD, T.F. Green International Airport, Providence, RI
* Alternate airport: MHT, Manchester Airport, Manchester, NH

== Things to do ==

Several people from the Tesora team are from the Boston area. Contact any of us.

Trove/JunoMidCycleMeetup

2014-08-15T15:07:01Z

Doug Shelley:

= Database Program (Trove) - Juno Mid-cycle Meetup =

== What ==

There will be a mid-cycle meetup for ATCs (Active Technical Contributors) to the OpenStack Database program in August, 2014.
The final schedule of topics will be determined by those that attend, shortly before the event.

Tesora [http://www.tesora.com] is helping organize this event.

== When ==

3 days, August 20-22, 2014

== Where ==

The MidCycle Meetup will be held at MIT (CSAIL), in Cambridge, MA.

The meetings will be in building 32 [http://whereis.mit.edu/?go=32]

== Event Details ==
On Tuesday, from 9AM to 5PM, Tesora is organizing an OpenStack Trove Day, a day of events about OpenStack with a focus on Trove. If you are attending the mid-cycle meetup, consider attending this event as well. Contact Amrith (amrith (at) tesora (dot) com, or amrith on IRC) or Doug (doug (at) tesora (dot) com, or dougshelley66 on IRC) for more details

{| class="wikitable"
|-
! Time !! Wed !! Thr !! Fri
|-
| 9-11 || Meets and greets || State of CI and Testing || OpenStack Integration (oslo, ceilometer, etc)
|-
| 11-1 || Show and tell - Juno Edition || Replication and Failover || Capabilities
|-
| 1-3 || Current state of blueprints || Clustering Next Steps || UI / Horizon update
|-
| 3-5 || Current state of Docs || Heat Update || Parking Lot
|}

=== Registration ===
* Please confirm your attendance at https://www.eventbrite.com/e/openstack-mid-cycle-meetup-tickets-11663001351

=== Key Signing Party ===

If there is interest, we will conduct a Key Signing Party
More details at: https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Trove_Icehouse_Sprint

=== Registration ===
** Please confirm your attendance ASAP at [https://trove-midcycle-meetup-2014.eventbrite.com]

=== Hotels ===
Hotels close to the event (closest on the top of the list).

Cambridge Marriott, 50 Broadway, Cambridge [http://www.marriott.com/hotels/travel/boscb-boston-marriott-cambridge/]

We have a block of rooms here at $259 per night. The advertised rates are much higher ($324). When booking be sure to ask for the "Tesora" event rate.

There are several other hotels in the neighborhood. If you get a much better deal, please update this page so others can benefit from it.

'''UPDATE: The block is for the mid-cycle meetup as well as people who are attending the Trove event sponsored by Tesora. They'll fill up fast, book quickly. Cambridge is expensive and other options are likely to be a lot more pricey.'''

=== Travel ===
* Recommended airport: BOS, Boston Logan International Airport, Boston, MA
* Alternate airport: PVD, T.F. Green International Airport, Providence, RI
* Alternate airport: MHT, Manchester Airport, Manchester, NH

== Things to do ==

Several people from the Tesora team are from the Boston area. Contact any of us.

Trove/JunoMidCycleMeetup

2014-08-15T15:06:36Z

Doug Shelley:

= Database Program (Trove) - Juno Mid-cycle Meetup =

== What ==

There will be a mid-cycle meetup for ATCs (Active Technical Contributors) to the OpenStack Database program in August, 2014.
The final schedule of topics will be determined by those that attend, shortly before the event.

Tesora [http://www.tesora.com] is helping organize this event.

== When ==

3 days, August 20-22, 2014

== Where ==

The MidCycle Meetup will be held at MIT (CSAIL), in Cambridge, MA.

The meetings will be in building 32 [http://whereis.mit.edu/?go=32]

== Event Details ==
On Tuesday, from 9AM to 5PM, Tesora is organizing an OpenStack Trove Day, a day of events about OpenStack with a focus on Trove. If you are attending the mid-cycle meetup, consider attending this event as well. Contact Amrith (amrith (at) tesora (dot) com, or amrith on IRC) or Doug (doug (at) tesora (dot) com, or dougshelley66 on IRC) for more details

{| class="wikitable"
|-
! Time !! Wed !! Thr !! Fri
|-
| 9-11 || Meets and greets || State of CI and Testing || OpenStack Integration (oslo, ceilometer, etc)
|-
| 11-1 || Show and tell - Juno Edition || Replication and Failover || Capabilities
|-
| 1-3 || Current state of blueprints || Clustering Next Steps || UI / Horizon update
|-
| 3-5 || Current state of Docs || Heat Update || Parking Lot
|}

=== Registration ===
** Please confirm your attendance at https://www.eventbrite.com/e/openstack-mid-cycle-meetup-tickets-11663001351

=== Key Signing Party ===

If there is interest, we will conduct a Key Signing Party
More details at: https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Trove_Icehouse_Sprint

=== Registration ===
** Please confirm your attendance ASAP at [https://trove-midcycle-meetup-2014.eventbrite.com]

=== Hotels ===
Hotels close to the event (closest on the top of the list).

Cambridge Marriott, 50 Broadway, Cambridge [http://www.marriott.com/hotels/travel/boscb-boston-marriott-cambridge/]

We have a block of rooms here at $259 per night. The advertised rates are much higher ($324). When booking be sure to ask for the "Tesora" event rate.

There are several other hotels in the neighborhood. If you get a much better deal, please update this page so others can benefit from it.

'''UPDATE: The block is for the mid-cycle meetup as well as people who are attending the Trove event sponsored by Tesora. They'll fill up fast, book quickly. Cambridge is expensive and other options are likely to be a lot more pricey.'''

=== Travel ===
* Recommended airport: BOS, Boston Logan International Airport, Boston, MA
* Alternate airport: PVD, T.F. Green International Airport, Providence, RI
* Alternate airport: MHT, Manchester Airport, Manchester, NH

== Things to do ==

Several people from the Tesora team are from the Boston area. Contact any of us.

Trove/Replication-And-Clustering-With-Nodes-3

2014-05-08T13:22:53Z

Doug Shelley:

== Example: Cassandra ==
 
To illustrate the approach, Cassandra is used in the examples below. The eccentricities of each Datastore will be explained in their own sections.
 
 
==== Create Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "products",
"datastore": {
"type": "cassandra",
"version": "2.0.6"
},
"configuration": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"flavorRef": "7",
"volume": {
"size": 1
},
"cluster": {
"size": 3,
"nodes": [
{"region": "phx"},
{"region": "slc"},
{"region": "lvs"}
]
}
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "cassandra",
"version": "2.0.6"
},
"cluster": {
"size": 3,
"nodes": [
{"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1", "region": "phx"},
{"id": "7f52e4f9-3fa6-4238-ac08-1ce15197329a", "region": "slc"},
{"id": "ff9d680c-fde3-49c6-a84e-76173b6df39d", "region": "lvs"}
]
}
}
}
</pre>
 
Notes:
* For Phase One:
** cluster.nodes{} will not be supported.
** cluster.nodes[].region will not be returned.
* For Phase Two:
** if cluster.allocations{} is not provided, the current region is assumed.
** cluster.nodes[].region will always be returned.
* Cassandra-specific fields that are required to construct the initial cluster (num_tokens, endpoint_snitch, seed ip-list, etc.) are to be determined/calculated based on configuration file values and common-sense.

 
==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "cassandra",
"version": "2.0.6"
},
"cluster": {
"size": 3,
"nodes": [
{"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1", "region": "phx"},
{"id": "7f52e4f9-3fa6-4238-ac08-1ce15197329a", "region": "slc"},
{"id": "ff9d680c-fde3-49c6-a84e-76173b6df39d", "region": "lvs"}
]
}
}
}
</pre>
 
Notes:
* In Phase One:
** cluster.nodes[].region will not be returned.
* Change: instance.volume.used, instance.ip[], and instance.hostname will never be returned
** It's possible that instance.ip[] can remain if it only returns the seed ips.
** It's possible that instance.hostname can remain if it's converted to an array and only contains the seed hostnames.
 
==== Show Node ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/nodes/416b0b16-ba55-4302-bbd3-ff566032e1c1
</pre>

Response:

<pre>
{
"node": {
"status": "ACTIVE",
"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1",
"name": "products-1",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"ip": ["10.0.0.1"],
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"links": [{...}],
},
"flavor": {
"id": "7",
"links": [{...}],
},
"volume": {
"size": 2,
"used": 0.17
}
}
}
</pre>
 
==== Add Node(s) ====
 
Request:

<pre>
POST /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/nodes
{
"nodes": {
"num": 2,
"allocations": [
{"region": "phx"},
{"region": "phx"}
]
}
}
</pre>
 
Response:
<pre>
HTTP 202 (Empty Body)
</pre>
 
Notes:
* For Phase One:
** nodes.num will be the only supported field (nodes.allocations will not)
* For Phase Two:
** if nodes.allocations[] is not provided, the region of every existing node must match, otherwise the request is failed.
 
==== Replace Node ====
 
Request:

<pre>
POST /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/action

{
"replace_node": {
"id": "7f52e4f9-3fa6-4238-ac08-1ce15197329a"
}
}
</pre>
 
Response:
<pre>
HTTP 202 (Empty Body)
</pre>
 
Notes:
* http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_live_node.html
* http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_seed_node.html
* http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html
 

==== Remove Node ====
 
Request:

<pre>
DELETE /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/nodes/7f52e4f9-3fa6-4238-ac08-1ce15197329a
</pre>
 
Response:
<pre>
HTTP 202 (Empty Body)
</pre>
 
Notes:
* http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_remove_node_t.html
 

== Example: MongoDB ==
 
==== Create Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "products",
"datastore": {
"type": "mongodb",
"version": "2.4.10"
},
"configuration": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"flavorRef": "7",
"volume": {
"size": 1
},
"cluster": {
"size": 5,
"nodes": [
{"region": "phx"},
{"region": "phx"},
{"region": "phx"},
{"region": "slc"},
{"region": "slc"}
]
}
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mongodb",
"version": "2.4.10"
},
"cluster": {
"size": 5,
"nodes": [
{"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1", "region": "phx"},
{"id": "965ef811-7c1d-47fc-89f2-a89dfdd23ef2", "region": "phx"},
{"id": "3642f41c-e8ad-4164-a089-3891bf7f2d2b", "region": "phx"},
{"id": "7f52e4f9-3fa6-4238-ac08-1ce15197329a", "region": "slc"},
{"id": "ff9d680c-fde3-49c6-a84e-76173b6df39d", "region": "slc"}
]
}
}
}
</pre>
 

==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mongodb",
"version": "2.4.10"
},
"cluster": {
"size": 5,
"nodes": [
{"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1", "region": "phx"},
{"id": "965ef811-7c1d-47fc-89f2-a89dfdd23ef2", "region": "phx"},
{"id": "3642f41c-e8ad-4164-a089-3891bf7f2d2b", "region": "phx"},
{"id": "7f52e4f9-3fa6-4238-ac08-1ce15197329a", "region": "slc"},
{"id": "ff9d680c-fde3-49c6-a84e-76173b6df39d", "region": "slc"}
]
}
}
}
</pre>
 

==== Show Node ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/nodes/416b0b16-ba55-4302-bbd3-ff566032e1c1
</pre>

Response:

<pre>
{
"node": {
"status": "ACTIVE",
"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1",
"name": "products-1",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"ip": ["10.0.0.1"],
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"links": [{...}],
},
"flavor": {
"id": "7",
"links": [{...}],
},
"volume": {
"size": 2,
"used": 0.17
}
}
}
</pre>
 
==== Create Arbiter(s) ====
 
Request:

<pre>
POST /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/nodes

{
"nodes": {
"num": 2,
"allocations": [
{"region": "lvs", "type": "arbiter"},
{"region": "lvs", "type": "arbiter"}
]
}
}
</pre>

Response:

<pre>
HTTP 202 (Empty Body)
</pre>
 

==== Show Cluster (After Arbiters) ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mongodb",
"version": "2.4.10"
},
"cluster": {
"size": 7,
"nodes": [
{"id": "416b0b16-ba55-4302-bbd3-ff566032e1c1", "region": "phx"},
{"id": "965ef811-7c1d-47fc-89f2-a89dfdd23ef2", "region": "phx"},
{"id": "3642f41c-e8ad-4164-a089-3891bf7f2d2b", "region": "phx"},
{"id": "7f52e4f9-3fa6-4238-ac08-1ce15197329a", "region": "slc"},
{"id": "ff9d680c-fde3-49c6-a84e-76173b6df39d", "region": "slc"},
{"id": "77032c55-4496-4e35-8c0d-6cd1c18e1a9c", "region": "lvs", "type": "arbiter"},
{"id": "1fd054ed-221f-4c99-8d17-570bcff4c1d2", "region": "lvs", "type": "arbiter"}
]
}
}
}
</pre>
 

== Example: MySQL ==
 
==== Create Master ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "products",
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"flavorRef": "7",
"volume": {
"size": 1
}
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"links": [{...}],
},
"flavor": {
"id": "7",
"links": [{...}],
},
"volume": {
"size": 1
}
}
}
</pre>
 

==== Create Slave ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "products-slave",
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": "fc318e00-3a6f-4f93-af99-146b44912188",
"flavorRef": "7",
"volume": {
"size": 1
},
"slave": {
"of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
}
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": {
"id": "fc318e00-3a6f-4f93-af99-146b44912188",
"links": [{...}],
},
"flavor": {
"id": "7",
"links": [{...}],
},
"volume": {
"size": 1
},
"slave": {
"of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
}
}
}
</pre>
 
==== Show Master ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"links": [{...}],
},
"flavor": {
"id": "7",
"links": [{...}],
},
"volume": {
"size": 1
},
"slave": {
"list": [
{"id": "061aaf4c-3a57-411e-9df9-2d0f813db859"}
]
}
}
}
</pre>
 
==== Show Slave ====
 
Request:

<pre>
GET /instances/061aaf4c-3a57-411e-9df9-2d0f813db859
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "products",
"created": "2014-04-25T20:19:23",
"updated": "2014-04-25T20:19:23",
"links": [{...}],
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": {
"id": "fc318e00-3a6f-4f93-af99-146b44912188",
"links": [{...}],
},
"flavor": {
"id": "7",
"links": [{...}],
},
"volume": {
"size": 1
},
"slave": {
"of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
}
}
}
</pre>
 
==== Promote (Detach) Slave ====
 
Request:

<pre>
POST /instances/061aaf4c-3a57-411e-9df9-2d0f813db859/action

{
"promote": {}
}
</pre>

Response:

<pre>
HTTP 202 (Empty Body)
</pre>
 
==== Delete Slave ====
 
Request:

<pre>
DELETE /instances/061aaf4c-3a57-411e-9df9-2d0f813db859
</pre>
 
Response:
<pre>
HTTP 202 (Empty Body)
</pre>
 
== Data Model Changes ==
=== Nodes Table ===
Create a new 'nodes' Table:
<pre>
CREATE TABLE "nodes" (
"id" varchar(36) NOT NULL,
"instance_id" varchar(36) NOT NULL,
"created" datetime DEFAULT NULL,
"updated" datetime DEFAULT NULL,
"name" varchar(255) DEFAULT NULL,
"hostname" varchar(255) DEFAULT NULL,
"compute_instance_id" varchar(36) DEFAULT NULL,
"task_id" int(11) DEFAULT NULL,
"task_description" varchar(32) DEFAULT NULL,
"task_start_time" datetime DEFAULT NULL,
"volume_id" varchar(36) DEFAULT NULL,
"flavor_id" int(11) DEFAULT NULL,
"volume_size" int(11) DEFAULT NULL,
"tenant_id" varchar(36) DEFAULT NULL,
"server_status" varchar(64) DEFAULT NULL,
"deleted" tinyint(1) DEFAULT NULL,
"deleted_at" datetime DEFAULT NULL,
"datastore_version_id" varchar(36) NOT NULL,
"configuration_id" varchar(36) DEFAULT NULL,
PRIMARY KEY ("id"),
KEY "instance_id" ("instance_id"),
KEY "datastore_version_id" ("datastore_version_id"),
KEY "configuration_id" ("configuration_id"),
KEY "instances_tenant_id" ("tenant_id"),
KEY "instances_deleted" ("deleted"),
CONSTRAINT "nodes_ibfk_3" FOREIGN KEY ("instance_id") REFERENCES "instances" ("id"),
CONSTRAINT "nodes_ibfk_2" FOREIGN KEY ("configuration_id") REFERENCES "configurations" ("id"),
CONSTRAINT "nodes_ibfk_1" FOREIGN KEY ("datastore_version_id") REFERENCES "datastore_versions" ("id")
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
</pre>
 
aka the same table as instances, except:
* addition of: "instance_id" varchar(36) NOT NULL
* addition of: KEY "instance_id" ("instance_id")
* addition of: CONSTRAINT "instances_ibfk_3" FOREIGN KEY ("instance_id") REFERENCES "instances" ("id"),
* TODO: changing of 'DEFAULT NULL' to 'NOT NULL' whenever possible (ex: things like CREATED should never be NULL)
* TODO: addition of removal of indexes as deemed necessary
 
=== Alter Instances Table ===
Add slave_of Column to Instances Table (+ Constraint + Index):
<pre>
ALTER TABLE nodes ADD COLUMN slave_of VARCHAR(36) DEFAULT NULL;
KEY "slave_of" ("slave_of"),
CONSTRAINT "instances_ibfk_3" FOREIGN KEY ("slave_of") REFERENCES "instances" ("id")
</pre>
 
=== Alter Other Tables ===
Add node_id column to the following tables:
* agent_heartbeats
* backups
* conductor_lastseen
* root_enabled_history
* security_group_instance_associations
* service_statuses
* usage_events
 
<pre>
ALTER TABLE <table> ADD COLUMN node_id VARCHAR(36) DEFAULT NULL;
KEY "node_id" ("node_id"),
CONSTRAINT "<table>_ibfk_<num>" FOREIGN KEY ("node_id") REFERENCES "nodes" ("id")
</pre>
 
== TaskManager ==

* add node_id to /etc/guest_info (if it's a node in a cluster). guest_id remains as-is.
* for-loop create each node.
* poll until all nodes are active.
* for each node: use trove/nova to get ip/hostname
* for couchbase:
** send ip/hostname list via rpc cast to guest
* for cassandra:
** send seed ip list via rpc cast to guest seed nodes, one by one (polling on REBOOT => ACTIVE), then to rest of nodes.
* for mongodb:
** send ip/hostname list via rpc cast to guest that is the db.isMaster()
 

== Guest ==

* update heartbeat payload ( heartbeat(guest_id, payload, sent) ) from {"service_status": "<status>"} to {"service_status": "<status>", "node_id": "<node-id>"}
* add method to each datastore guest manager for handling ip/hostname list
 

== Conductor ==

* update heartbeat logic to update the nodes table (node status)
 

== Capabilities ==
 
A capability might be supported for a datastore-version for standalone instances, but not for clusters.
Therefore, the capability tables must be amended to include a cluster-enabled flag.

<pre>
ALTER TABLE capabilities ADD COLUMN enabled_cluster TINYINT(1) DEFAULT NULL;
</pre>
<pre>
ALTER TABLE capability_overrides ADD COLUMN enabled_cluster TINYINT(1) DEFAULT NULL;
</pre>
The following capabilities should have enabled_cluster set to false for the first iteration of clusters:
* backup-create + list-instance
* configuration-attach + detach + instances
* resize-<all>
* database-<all>
* root-<all>
* secgroup-<all>
* user-<all>
 
== Configuration Groups ==
 
=== Introduce read_only and hidden Parameters ===
Need to introduce two additional attributes for configuration group parameters: read_only and hidden.
* read_only fields include cluster_name, num_tokens, seed_provider, seeds, endpoint_snitch (cassandra) + replSet (mongodb) + server_id, log_bin (mysql).
* depending on the provider, some of the read_only fields should also be hidden from the user on a configuration-show.
* once read_only + hidden are available, a parallel effort should move configuration-default to configurations-show if a configuration-group is attached.
 
=== Auto-Create and Attach ===
* cassandra & mongodb need to have configuration-groups automatically created and attached to each node (for cluster_name, replset, etc.) during provisioning.
* unique configuration-group per node.
* auto-created+attached configuration-groups need to not be detachable from the instance.
* dependency: configuration-group support for mongodb + cassandra
 
== Feedback ==

==== Create Slave ====

*glucas: Replication will require capturing a snapshot of the master's state and passing that to the slave. It would be preferable to create multiple slaves from a single snapshot and then clean up, rather than repeating the snapshot process multiple times. For that reason we propose a 'replicate' action that can create N slaves from an existing master in one call. I believe this approach works with the schema changes proposed here, i.e. adding the ''slave_of'' reference to the instance table.

==== Capabilities ====

*glucas: We should use capabilities to indicate whether a datastore supports replication (and potentially read-only vs. read-write replication). In the first iteration, replication will not be supported for clusters.

==== Configuration Groups ====
*dougshelley66: What if the end user wants to specify some configuration parameters for nodes or replicas? It appears (from the description above) that each node will have an auto generated group attached. Given an instance can only have one config group, this would allow the user to specify one?

Meetings/TroveMeeting

2014-04-22T22:50:22Z

Doug Shelley:

= 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:

An agenda item should have a clearly defined objective.

* 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.

Meeting Chat Logs: http://eavesdrop.openstack.org/meetings/trove/2014/

Meeting Agenda History: https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory

=== Agenda for Weekly Trove Team Meeting - April 23 ===
* Juno Mid-cycle Meetup - discuss venue/timing proposal and confirm

= Weekly Trove Blueprint Meeting =

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 Weekly Trove Blueprint Meeting - April 28 ===

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-28T14:16:10Z

Doug Shelley: /* Use Case Requirements */

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== Use Case Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen as the use-cases that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the slave such that the master already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# The health of a slave will be monitaorable

# (When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master) ''(not needed for v1; to be addressed later -SlickNik)''
# (All slaves should be in the same zone. (is this necessary or desired?) ''(not needed for v1; to be addressed later -SlickNik)''

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Swift
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Scope ==
Phase I implementation, targeted for the Juno release, will implement Use Case A core functionality and the MySql datastore replication support. Replication support for other datastores beyond MySQL are beyond the scope of this blueprint and will be covered elsewhere.

== Impacts ==
This change would impact all components of Trove.

=== Configuration ===
There should be no changes to configuration files required.

=== Database ===

* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

The addition of a replication feature would required changes to the trove command and corresponding APIs. At a minimum, there would need to be APIs to add a slave to a master, and to remove a slave from a master. Additionally, there may be changes to how a potential master site is created.

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

There would be API changes at every level to support replication.

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

The guest agent would require support for the new replication operations, but backward compatibility should be maintained.

Meetings/TroveMeeting

2014-03-07T16:24:16Z

Doug Shelley:

= Weekly Trove (DBaaS) team meeting =

For those interested, we have meetings in #openstack-meeting-alt Weekly, Wednesdays at 18:00 UTC. Feel free to add items in the agenda below.

Logs available: http://eavesdrop.openstack.org/meetings/trove/2014/

== Agenda for todays meeting ==
* [https://wiki.openstack.org/w/index.php?title=Trove-Guest-Agent-Upgrades Guest Agent Upgrades Wiki]
* Update from the Clustering meeting / details of vote

== Agenda for Mar. 12 ==
* Trove Guest Agent Upgrades bp follow up
** https://blueprints.launchpad.net/trove/+spec/upgrade-guestagent
* DBLog feature
**https://blueprints.launchpad.net/trove/+spec/dbinstance-log
*Point in time recovery
**https://blueprints.launchpad.net/trove/+spec/point-in-tyme-recovery
**https://blueprints.launchpad.net/trove/+spec/mysql-point-in-time-recovery
*Additional validation for the restore process
**https://blueprints.launchpad.net/trove/+spec/datastore-type-version-to-backp-model
* Replication version 1
**https://blueprints.launchpad.net/trove/+spec/replication-v1

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:31:15Z

Doug Shelley:

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== Use Case Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen as the use-cases that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the slave such that the master already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Scope ==
This blueprint will endeavour to specify implementation against the following requirements:
* MySQL only
* Use Case Requirements A.

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:28:39Z

Doug Shelley: /* High Level Requirements */

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== Use Case Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen as the use-cases that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the master such that it already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:16:21Z

Doug Shelley: /* High Level Requirements */

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== High Level Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen as the use-cases that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the master such that it already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:15:30Z

Doug Shelley: /* High Level Requirements */

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== High Level Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen at the overall requirements that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the master such that it already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:15:16Z

Doug Shelley: /* High Level Requirements */

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== High Level Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen at the overall requirements that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the master such that it already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:14:55Z

Doug Shelley: /* High Level Requirements */

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== High Level Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen at the overall requirements that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the master such that it already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery
# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover
# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-05T00:14:37Z

Doug Shelley:

== Description ==
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.

== Justification/Benefits ==
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
* scale out via read replicas
* operational recovery (aka failover)
* offline backup

In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.

Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.

== High Level Requirements ==
While the specific details of each datastore need to be investigated against this list, these are seen at the overall requirements that would motivate the replication feature:

A. Read Replicas (Slaves)
# The master can exist before the master such that it already contains data
# N Slaves for one master
# Slaves can be marked read-only (probably by default)
# When master fails, a slave can be chosen to be promoted to new master, with other slaves switched to follow new master
# A slave can be detached from "replication set" to act as independent site
# A pre-existing non-replication site can become the master of a new "replication set"
# All slaves should be in the same zone. (is this necessary or desired?)

B. MultiZone Disaster Recovery

# A master in one zone is mirrored by a slave in a different zone
# Some mechanism should exist where cloud admin can set up "zone configuration" so that the user can simply select "MultiZone DR" and Trove will know where to put both the master and the slave
# Should be able to restore master from slave, either directly or by making backup stored in Glance
# Should be able to "click the switch" on an already running mysql instance

C. Single Zone Failover

# Implements master-master replication between 2 instances in the same zone
# Can be set up on pre-existing instance
# Should be able to switch "active master", i.e., the site to which data is being written (other site could be marked read-only)

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-04T22:14:54Z

Doug Shelley: /* Justification/Benefits */

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-04T22:07:13Z

Doug Shelley: /* Description */

Trove/Blueprints/Trove-v1-MySQL-Replication

2014-03-04T22:05:17Z

Doug Shelley: Created page with "== Description == Describe the purpose of the enhancement == Justification/Benefits == * What is the driving force behind this change? * Does it allow for great flexibility..."

== Description ==
Describe the purpose of the enhancement

== Justification/Benefits ==
* What is the driving force behind this change?
* Does it allow for great flexibility? Stability? Security?

== Impacts ==

=== Configuration ===
* Does this impact any configuration files? If so, which ones?

=== Database ===
* Does this impact any existing tables? If so, which ones?
* Are the changes forward and backward compatible?
* Be sure to include the expected migration process

=== Public API ===
* Does this change any API that an end-user has access to?
* Are there any exceptions in terms of consistency with other APIs?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest

=== Guest Agent ===
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?

OpenPGP Web of Trust/Trove Icehouse Sprint

2014-02-17T20:20:51Z

Doug Shelley: /* Trove Mid-Cycle Icehouse Sprint Key Signing */

= Trove Mid-Cycle Icehouse Sprint Key Signing =
If you plan to join us, please bring one or more forms of photo identification, and make sure the real name on your key corresponds to the name on your ID. If you want additional tips, see the [[OpenPGP Web of Trust#Key Signing Process|parent article]].

If you want to bring cards or pieces of paper with your name and key fingerprint then feel free, but if you add your information to the table below we will do our best to bring paper copies (at least enough for the people who are listed here) for use as a checklist so that you won't need to use your computer. Please bring extra pens or pencils however, if you can, since there may not be many of those to go around.

{| class="wikitable"
|+ People participating in identification exchange
! Real Name !! IRC Nick !! Key Fingerprint !! Preferred E-mail Address
|-
| Nikhil Manchanda || slicknik || 5674 7211 71F8 CD59 F285 353D 9692 757E BCD3 D66C || nikhil@manchanda.me
|-
| Steve Leon || esmute || 02F1 F2AE C17D 66D2 1B1B B75C EF3B 2AB9 FFF4 F9EA || steve.leon@hp.com
|-
| Justin Hopper || juice || 7463 498F 7D3B 7DB3 FFBF 4946 C02F 046F '''EA23 8CF3''' || justin.hopper@me.com
|-
|Michael Basnight||hub_cap||9D60 7133 8AFE 4FE5 45D9 625E 9E86 DD8C 3DB5 897B||mbasnight@gmail.com
|-
|Craig Vyvial||cp16net||8975 C9C2 E879 309A 771B 7C01 046B FABA F4BD 6CC2||cp16net@gmail.com
|-
|Dan Nguyen||esp||D9D4 F72E 82FC EFCE 1923 B140 9163 F056 AE67 298E||dan.nguyens.mail@gmail.com
|-
|Daniel Salinas||imsplitbit||54C5 515E 71FB 1533 2332 F115 78EE B83C 964B C17C||imsplitbit@gmail.com
|-
|Andrew Bramley||abramley||7082 00CC 9C6F 7523 C3B1 2CB4 9E67 CA34 2DAA 044F||andrew@tesora.com
|-
|Amrith Kumar||amrith||0D22 859E BE93 63F5 9DD6 35BC 5E48 849A 9D21 A29B||amrith@tesora.com
|-
|Paul Marshall||pdmars||2DCA A0AB 6DEC A717 FC80 A6D1 9F08 2613 795C B691||paul.marshall@rackspace.com
|-
|Vipul Sabhaya||vipul||B7FA 44B3 32C7 1A3A F606 1ED7 A2C7 95BC 02AE 77A2 ||vipul.sabhaya@hp.com
|-
|Doug Shelley||dougshelley66||95FB 1D3D 900D 67F9 FDA9 C378 6B34 FD08 BA22 5C73||doug@tesora.com
|}

Trove/DevelopingOnEC2

2014-01-08T22:33:29Z

Doug Shelley:

Stay Tuned!