https://wiki.openstack.org/w/api.php?action=feedcontributions&feedformat=atom&user=Robert+MyersOpenStack - User contributions [en]2026-07-12T08:45:08ZUser contributionsMediaWiki 1.28.2https://wiki.openstack.org/w/index.php?title=Meetings/TroveMeeting&diff=65057Meetings/TroveMeeting2014-10-15T14:38:00Z<p>Robert Myers: /* Agenda for Oct 15th */</p>
<hr />
<div>= Weekly Trove Team Meeting =<br />
<br />
We have weekly team meetings on Wednesdays at 18:00 UTC in #openstack-meeting-alt<br />
<br />
Want to add an agenda item? Please append your item to the upcoming weekly agenda while keeping in mind:<br />
<br />
== Guidelines for Writing Clear Agenda Items ==<br />
An agenda item should have a clearly defined objective.<br />
<br />
* 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.<br />
* Bad: Discuss blueprint ‘xyz’<br />
* Bad: Revisit blueprint ‘abc’ that we talked about last week to get answers on remaining disagreements.<br />
<br />
<br />
When referring to previous conversations or competing viewpoints, be sure to summarize them.<br />
<br />
== Agenda for Oct 15th ==<br />
* 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)<br />
** https://review.openstack.org/#/c/119425/<br />
<br />
== Agenda for Oct 8 ==<br />
* Discuss if change to rdservers related logic in load_mgmt_instance is acceptable as part of bugfix<br />
** https://bugs.launchpad.net/trove/+bug/1376525<br />
* FOSS Outreach Program Projects<br />
** http://gnome.org/opw/<br />
<br /><br /><br />
Meeting Chat Logs: http://eavesdrop.openstack.org/meetings/trove/2014/<br />
<br /><br />
Meeting Agenda History: https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory#Trove_Weekly_Meeting_Agenda_History<br />
<br /><br /><br />
<big>Note: BP Meetings now have their own wiki page at: https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting</big></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Meetings/TroveMeeting&diff=65055Meetings/TroveMeeting2014-10-15T14:36:46Z<p>Robert Myers: </p>
<hr />
<div>= Weekly Trove Team Meeting =<br />
<br />
We have weekly team meetings on Wednesdays at 18:00 UTC in #openstack-meeting-alt<br />
<br />
Want to add an agenda item? Please append your item to the upcoming weekly agenda while keeping in mind:<br />
<br />
== Guidelines for Writing Clear Agenda Items ==<br />
An agenda item should have a clearly defined objective.<br />
<br />
* 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.<br />
* Bad: Discuss blueprint ‘xyz’<br />
* Bad: Revisit blueprint ‘abc’ that we talked about last week to get answers on remaining disagreements.<br />
<br />
<br />
When referring to previous conversations or competing viewpoints, be sure to summarize them.<br />
<br />
== Agenda for Oct 15th ==<br />
* 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.<br />
** https://review.openstack.org/#/c/119425/<br />
<br />
== Agenda for Oct 8 ==<br />
* Discuss if change to rdservers related logic in load_mgmt_instance is acceptable as part of bugfix<br />
** https://bugs.launchpad.net/trove/+bug/1376525<br />
* FOSS Outreach Program Projects<br />
** http://gnome.org/opw/<br />
<br /><br /><br />
Meeting Chat Logs: http://eavesdrop.openstack.org/meetings/trove/2014/<br />
<br /><br />
Meeting Agenda History: https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory#Trove_Weekly_Meeting_Agenda_History<br />
<br /><br /><br />
<big>Note: BP Meetings now have their own wiki page at: https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting</big></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=58369Trove/MoveTroveGuest2014-07-17T16:31:17Z<p>Robert Myers: /* add new openstack-common.conf */</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
* A new top level olso.cfg for the troveguest will be added. (This should be a small subset of the values in trove.common.cfg)<br />
* The values in trove.common.cfg that are specifically for the guest will be removed.<br />
* It is possible that some configuration values will need to be added or duplicated. <br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
=== Internal API ===<br />
None<br />
<br />
=== Guest Agent ===<br />
# The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
# The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
# Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
# The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)<br />
<br />
==== setup.cfg ====<br />
<br />
Add a new package to the [files] section<br />
<br />
<pre><br />
[files]<br />
packages =<br />
trove<br />
troveguest<br />
</pre><br />
<br />
==== new troveguest module =====<br />
<br />
Move the trove.guest module to troveguest so the layout looks like:<br />
<br />
<pre><br />
trove/<br />
...<br />
doc/<br />
etc/<br />
tools/<br />
trove/<br />
troveguest/ < --- new module<br />
setup.py<br />
setup.cfg <br />
... <br />
</pre><br />
<br />
==== add new openstack-common.conf ====<br />
<br />
Add file `troveguest/openstack-common.conf ` and add only the modules that the guest needs (this needs to be discoverd)<br />
<br />
# Clone the osloincubator repo: `git clone git@github.com:openstack/oslo-incubator.git`<br />
# Run the update script: `python update.py --config-file ../trove/troveguest/openstack-common.conf`<br />
<br />
Example config:<br />
<br />
<pre><br />
[DEFAULT]<br />
<br />
# The list of modules to copy from oslo-incubator<br />
module=eventlet_backdoor<br />
module=exception<br />
module=excutils<br />
module=fileutils<br />
module=gettextutils<br />
module=importutils<br />
module=jsonutils<br />
module=local<br />
module=lockutils<br />
module=log<br />
module=loopingcall<br />
module=pastedeploy<br />
module=periodic_task<br />
module=processutils<br />
module=rpc<br />
module=service<br />
module=strutils<br />
module=testutils<br />
module=threadgroup<br />
module=timeutils<br />
module=utils<br />
module=versionutils<br />
<br />
# The base module to hold the copy of openstack.common<br />
base=troveguest<br />
</pre><br />
<br />
==== Move tests and add a test runner for the guest ====<br />
<br />
The guestagent tests need to be split out from the trove.tests modules then we to make sure the tests are discovered properly. <br />
<br />
Possibly modify tox.ini:<br />
<br />
<pre><br />
[testenv:cover]<br />
basepython = python2.7<br />
commands =<br />
{envpython} run_tests.py --group=does_not_exist<br />
coverage erase<br />
python setup.py testr --coverage<br />
coverage run -a run_tests.py<br />
coverage run -a troveguest/run_tests.py<br />
coverage html<br />
coverage report<br />
</pre></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=58368Trove/MoveTroveGuest2014-07-17T16:11:30Z<p>Robert Myers: /* Move tests and add a test runner for the guest */</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
* A new top level olso.cfg for the troveguest will be added. (This should be a small subset of the values in trove.common.cfg)<br />
* The values in trove.common.cfg that are specifically for the guest will be removed.<br />
* It is possible that some configuration values will need to be added or duplicated. <br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
=== Internal API ===<br />
None<br />
<br />
=== Guest Agent ===<br />
# The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
# The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
# Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
# The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)<br />
<br />
==== setup.cfg ====<br />
<br />
Add a new package to the [files] section<br />
<br />
<pre><br />
[files]<br />
packages =<br />
trove<br />
troveguest<br />
</pre><br />
<br />
==== new troveguest module =====<br />
<br />
Move the trove.guest module to troveguest so the layout looks like:<br />
<br />
<pre><br />
trove/<br />
...<br />
doc/<br />
etc/<br />
tools/<br />
trove/<br />
troveguest/ < --- new module<br />
setup.py<br />
setup.cfg <br />
... <br />
</pre><br />
<br />
==== add new openstack-common.conf ====<br />
<br />
Add file `troveguest/openstack-common.conf ` and add only the modules that the guest needs (this needs to be discoverd)<br />
<br />
<pre><br />
[DEFAULT]<br />
<br />
# The list of modules to copy from oslo-incubator<br />
module=eventlet_backdoor<br />
module=exception<br />
module=excutils<br />
module=fileutils<br />
module=gettextutils<br />
module=importutils<br />
module=jsonutils<br />
module=local<br />
module=lockutils<br />
module=log<br />
module=loopingcall<br />
module=pastedeploy<br />
module=periodic_task<br />
module=processutils<br />
module=rpc<br />
module=service<br />
module=strutils<br />
module=testutils<br />
module=threadgroup<br />
module=timeutils<br />
module=utils<br />
module=versionutils<br />
<br />
# The base module to hold the copy of openstack.common<br />
base=troveguest<br />
</pre><br />
<br />
==== Move tests and add a test runner for the guest ====<br />
<br />
The guestagent tests need to be split out from the trove.tests modules then we to make sure the tests are discovered properly. <br />
<br />
Possibly modify tox.ini:<br />
<br />
<pre><br />
[testenv:cover]<br />
basepython = python2.7<br />
commands =<br />
{envpython} run_tests.py --group=does_not_exist<br />
coverage erase<br />
python setup.py testr --coverage<br />
coverage run -a run_tests.py<br />
coverage run -a troveguest/run_tests.py<br />
coverage html<br />
coverage report<br />
</pre></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=58367Trove/MoveTroveGuest2014-07-17T16:05:58Z<p>Robert Myers: /* Guest Agent */</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
* A new top level olso.cfg for the troveguest will be added. (This should be a small subset of the values in trove.common.cfg)<br />
* The values in trove.common.cfg that are specifically for the guest will be removed.<br />
* It is possible that some configuration values will need to be added or duplicated. <br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
=== Internal API ===<br />
None<br />
<br />
=== Guest Agent ===<br />
# The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
# The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
# Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
# The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)<br />
<br />
==== setup.cfg ====<br />
<br />
Add a new package to the [files] section<br />
<br />
<pre><br />
[files]<br />
packages =<br />
trove<br />
troveguest<br />
</pre><br />
<br />
==== new troveguest module =====<br />
<br />
Move the trove.guest module to troveguest so the layout looks like:<br />
<br />
<pre><br />
trove/<br />
...<br />
doc/<br />
etc/<br />
tools/<br />
trove/<br />
troveguest/ < --- new module<br />
setup.py<br />
setup.cfg <br />
... <br />
</pre><br />
<br />
==== add new openstack-common.conf ====<br />
<br />
Add file `troveguest/openstack-common.conf ` and add only the modules that the guest needs (this needs to be discoverd)<br />
<br />
<pre><br />
[DEFAULT]<br />
<br />
# The list of modules to copy from oslo-incubator<br />
module=eventlet_backdoor<br />
module=exception<br />
module=excutils<br />
module=fileutils<br />
module=gettextutils<br />
module=importutils<br />
module=jsonutils<br />
module=local<br />
module=lockutils<br />
module=log<br />
module=loopingcall<br />
module=pastedeploy<br />
module=periodic_task<br />
module=processutils<br />
module=rpc<br />
module=service<br />
module=strutils<br />
module=testutils<br />
module=threadgroup<br />
module=timeutils<br />
module=utils<br />
module=versionutils<br />
<br />
# The base module to hold the copy of openstack.common<br />
base=troveguest<br />
</pre><br />
<br />
==== Move tests and add a test runner for the guest ====<br />
<br />
The guestagent tests need to be split out from the trove.tests modules then we to make sure the tests are discovered properly. <br />
<br />
Possibly modify tox.ini:<br />
<br />
<pre><br />
[testenv:cover]<br />
basepython = python2.7<br />
commands =<br />
{envpython} run_tests.py --group=does_not_exist<br />
coverage erase<br />
python setup.py testr --coverage<br />
coverage run -a run_tests.py<br />
coverage run -a troveguest/run_tests.py<br />
coverage html<br />
</pre><br />
coverage report</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=58366Trove/MoveTroveGuest2014-07-17T15:59:03Z<p>Robert Myers: /* Guest Agent */</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
* A new top level olso.cfg for the troveguest will be added. (This should be a small subset of the values in trove.common.cfg)<br />
* The values in trove.common.cfg that are specifically for the guest will be removed.<br />
* It is possible that some configuration values will need to be added or duplicated. <br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
=== Internal API ===<br />
None<br />
<br />
=== Guest Agent ===<br />
# The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
# The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
# Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
# The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)<br />
<br />
==== setup.cfg ====<br />
<br />
Add a new package to the [files] section<br />
<br />
<pre><br />
[files]<br />
packages =<br />
trove<br />
troveguest<br />
</pre><br />
<br />
==== new troveguest module =====<br />
<br />
Move the trove.guest module to troveguest so the layout looks like:<br />
<br />
<pre><br />
trove/<br />
...<br />
doc/<br />
etc/<br />
tools/<br />
trove/<br />
troveguest/ < --- new module<br />
setup.py<br />
setup.cfg <br />
... <br />
</pre><br />
<br />
==== add new openstack-common.conf ====<br />
<br />
Add file `troveguest/openstack-common.conf ` and add only the modules that the guest needs (this needs to be discoverd)<br />
<br />
<pre><br />
[DEFAULT]<br />
<br />
# The list of modules to copy from oslo-incubator<br />
module=eventlet_backdoor<br />
module=exception<br />
module=excutils<br />
module=fileutils<br />
module=gettextutils<br />
module=importutils<br />
module=jsonutils<br />
module=local<br />
module=lockutils<br />
module=log<br />
module=loopingcall<br />
module=pastedeploy<br />
module=periodic_task<br />
module=processutils<br />
module=rpc<br />
module=service<br />
module=strutils<br />
module=testutils<br />
module=threadgroup<br />
module=timeutils<br />
module=utils<br />
module=versionutils<br />
<br />
# The base module to hold the copy of openstack.common<br />
base=troveguest<br />
</pre></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Meetings/TroveMeeting&diff=48643Meetings/TroveMeeting2014-04-14T16:24:11Z<p>Robert Myers: /* Agenda for Apr. 14 (blueprint meeting) */</p>
<hr />
<div><br />
= Weekly Trove (DBaaS) team meeting =<br />
<br />
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.<br />
<br />
Logs available: http://eavesdrop.openstack.org/meetings/trove/2014/<br />
<br />
Meetings agenda history: [https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory link]<br />
<br />
== Agenda for Apr. 14 (blueprint meeting) ==<br />
* Datastore Capabilities [k-pom]<br />
** https://blueprints.launchpad.net/trove/+spec/capabilities<br />
*Descriptions to Datastore Configuration Group Parameters [cp16net]<br />
** https://blueprints.launchpad.net/trove/+spec/add-descriptions-to-config-parameters-api<br />
*Categorize the trove-manage commands [cp16net]<br />
** https://blueprints.launchpad.net/trove/+spec/categorize-the-trove-manage-commands<br />
*Point in time recovery [denis_makogon]<br />
** https://blueprints.launchpad.net/trove/+spec/point-in-time-recovery<br />
*Data volume snapshot [denis_makogon]<br />
** https://blueprints.launchpad.net/trove/+spec/volume-snapshot<br />
*Networking [denis_makogon]<br />
** https://blueprints.launchpad.net/trove/+spec/network-manager-spec<br />
* Move the Trove Guest Agent to its own module [robertmyers]<br />
** https://blueprints.launchpad.net/trove/+spec/moving-trove-guestagent<br />
* Database log files manipulations [denis_makogon]<br />
** https://blueprints.launchpad.net/trove/+spec/dbinstance-log<br />
* Unify common code in guest agent configurations [amrith and snowdust]<br />
** https://blueprints.launchpad.net/trove/+spec/trove-unify-common-code-for-config-of-guest-agent-variants<br />
* Adding datastore and version to the backup API [robertmyers]<br />
** https://blueprints.launchpad.net/trove/+spec/backup-metadata</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/backup-metadata&diff=48642Trove/backup-metadata2014-04-14T16:20:57Z<p>Robert Myers: /* Description */</p>
<hr />
<div>== Description ==<br />
This blueprint will add the datastore and version to the backups api response.<br />
<br />
Blueprint: https://blueprints.launchpad.net/trove/+spec/backup-metadata<br />
<br />
== Justification/Benefits ==<br />
* This will allow filtering the backups list by datastore type (and version?) <br />
* Eventually allow the api to restrict which datastore a backup could be restored to. (mysql -> mysql) (redis -> redis) <br />
<br />
== Impacts ==<br />
<br />
=== Configuration === <br />
None<br />
<br />
=== Database ===<br />
* The backup table will need to have a foreign key to the Datastore Version table.<br />
* This will require a migration to add the foreign key to all existing records<br />
<br />
=== Public API ===<br />
* This will add the datastore type and version to the API Response<br />
* This will also add the ability to filter the backup list by datastore<br />
<br />
==== CLI interface====<br />
* This will add a single param to backup-list command '--datastore' to filter the list by that datastore <br />
<br />
==== ReST Part ====<br />
==== New backup list Response: ====<br />
<pre><br />
HTTP/1.1 200 OK<br />
Content-Type: application/json<br />
Via: 1.1 Repose (Repose/2.6.7)<br />
Content-Length: 663<br />
Date: Thu, 13 Feb 2014 21:47:16 GMT<br />
Server: Jetty(8.0.y.z-SNAPSHOT)<br />
<br />
{<br />
"backups": [<br />
{<br />
"created": "2014-02-13T21:47:16", <br />
"datastore": {<br />
"type": "mysql",<br />
"version": "5.5"<br />
}<br />
"description": "My Backup", <br />
"id": "014cfa93-fd0e-4e9d-871f-da8bb2eeee3e", <br />
"instance_id": "dcf2c32b-241d-4c39-af70-1001dfe946d6", <br />
"locationRef": "http://localhost/path/to/backup", <br />
"name": "snapshot", <br />
"parent_id": null, <br />
"size": null, <br />
"status": "COMPLETED", <br />
"updated": "2014-02-13T21:47:16"<br />
}<br />
]<br />
}<br />
</pre><br />
<br />
==== New Backup GET by ID ====<br />
<pre><br />
HTTP/1.1 200 OK<br />
Content-Type: application/json<br />
Via: 1.1 Repose (Repose/2.6.7)<br />
Content-Length: 335<br />
Date: Thu, 13 Feb 2014 21:47:16 GMT<br />
Server: Jetty(8.0.y.z-SNAPSHOT)<br />
<br />
{<br />
"backup": {<br />
"created": "2014-02-13T21:47:16",<br />
"datastore": {<br />
"type": "mysql",<br />
"version": "5.5"<br />
}<br />
"description": "My Backup", <br />
"id": "61f12fef-edb1-4561-8122-e7c00ef26a82", <br />
"instance_id": "d4603f69-ec7e-4e9b-803f-600b9205576f", <br />
"locationRef": "http://localhost/path/to/backup", <br />
"name": "snapshot", <br />
"parent_id": null, <br />
"size": null, <br />
"status": "COMPLETED", <br />
"updated": "2014-02-13T21:47:16"<br />
}<br />
}<br />
</pre><br />
<br />
=== Internal API ===<br />
* No change in the internal api, only to the initial model creation code in the backup models.<br />
==== RPC API description====<br />
* No change<br />
<br />
=== Guest Agent ===<br />
* No Change</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/backup-metadata&diff=48636Trove/backup-metadata2014-04-14T16:15:38Z<p>Robert Myers: /* ReST Part */</p>
<hr />
<div>== Description ==<br />
This blueprint will add the datastore and version to the backups api response.<br />
<br />
== Justification/Benefits ==<br />
* This will allow filtering the backups list by datastore type (and version?) <br />
* Eventually allow the api to restrict which datastore a backup could be restored to. (mysql -> mysql) (redis -> redis) <br />
<br />
== Impacts ==<br />
<br />
=== Configuration === <br />
None<br />
<br />
=== Database ===<br />
* The backup table will need to have a foreign key to the Datastore Version table.<br />
* This will require a migration to add the foreign key to all existing records<br />
<br />
=== Public API ===<br />
* This will add the datastore type and version to the API Response<br />
* This will also add the ability to filter the backup list by datastore<br />
<br />
==== CLI interface====<br />
* This will add a single param to backup-list command '--datastore' to filter the list by that datastore <br />
<br />
==== ReST Part ====<br />
==== New backup list Response: ====<br />
<pre><br />
HTTP/1.1 200 OK<br />
Content-Type: application/json<br />
Via: 1.1 Repose (Repose/2.6.7)<br />
Content-Length: 663<br />
Date: Thu, 13 Feb 2014 21:47:16 GMT<br />
Server: Jetty(8.0.y.z-SNAPSHOT)<br />
<br />
{<br />
"backups": [<br />
{<br />
"created": "2014-02-13T21:47:16", <br />
"datastore": {<br />
"type": "mysql",<br />
"version": "5.5"<br />
}<br />
"description": "My Backup", <br />
"id": "014cfa93-fd0e-4e9d-871f-da8bb2eeee3e", <br />
"instance_id": "dcf2c32b-241d-4c39-af70-1001dfe946d6", <br />
"locationRef": "http://localhost/path/to/backup", <br />
"name": "snapshot", <br />
"parent_id": null, <br />
"size": null, <br />
"status": "COMPLETED", <br />
"updated": "2014-02-13T21:47:16"<br />
}<br />
]<br />
}<br />
</pre><br />
<br />
==== New Backup GET by ID ====<br />
<pre><br />
HTTP/1.1 200 OK<br />
Content-Type: application/json<br />
Via: 1.1 Repose (Repose/2.6.7)<br />
Content-Length: 335<br />
Date: Thu, 13 Feb 2014 21:47:16 GMT<br />
Server: Jetty(8.0.y.z-SNAPSHOT)<br />
<br />
{<br />
"backup": {<br />
"created": "2014-02-13T21:47:16",<br />
"datastore": {<br />
"type": "mysql",<br />
"version": "5.5"<br />
}<br />
"description": "My Backup", <br />
"id": "61f12fef-edb1-4561-8122-e7c00ef26a82", <br />
"instance_id": "d4603f69-ec7e-4e9b-803f-600b9205576f", <br />
"locationRef": "http://localhost/path/to/backup", <br />
"name": "snapshot", <br />
"parent_id": null, <br />
"size": null, <br />
"status": "COMPLETED", <br />
"updated": "2014-02-13T21:47:16"<br />
}<br />
}<br />
</pre><br />
<br />
=== Internal API ===<br />
* No change in the internal api, only to the initial model creation code in the backup models.<br />
==== RPC API description====<br />
* No change<br />
<br />
=== Guest Agent ===<br />
* No Change</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/backup-metadata&diff=48635Trove/backup-metadata2014-04-14T16:13:12Z<p>Robert Myers: </p>
<hr />
<div>== Description ==<br />
This blueprint will add the datastore and version to the backups api response.<br />
<br />
== Justification/Benefits ==<br />
* This will allow filtering the backups list by datastore type (and version?) <br />
* Eventually allow the api to restrict which datastore a backup could be restored to. (mysql -> mysql) (redis -> redis) <br />
<br />
== Impacts ==<br />
<br />
=== Configuration === <br />
None<br />
<br />
=== Database ===<br />
* The backup table will need to have a foreign key to the Datastore Version table.<br />
* This will require a migration to add the foreign key to all existing records<br />
<br />
=== Public API ===<br />
* This will add the datastore type and version to the API Response<br />
* This will also add the ability to filter the backup list by datastore<br />
<br />
==== CLI interface====<br />
* This will add a single param to backup-list command '--datastore' to filter the list by that datastore <br />
<br />
==== ReST Part ====<br />
New backup list Response:<br />
<pre><br />
HTTP/1.1 200 OK<br />
Content-Type: application/json<br />
Via: 1.1 Repose (Repose/2.6.7)<br />
Content-Length: 663<br />
Date: Thu, 13 Feb 2014 21:47:16 GMT<br />
Server: Jetty(8.0.y.z-SNAPSHOT)<br />
<br />
{<br />
"backups": [<br />
{<br />
"created": "2014-02-13T21:47:16", <br />
"datastore": {<br />
"type": "mysql",<br />
"version": "5.5"<br />
}<br />
"description": "My Backup", <br />
"id": "014cfa93-fd0e-4e9d-871f-da8bb2eeee3e", <br />
"instance_id": "dcf2c32b-241d-4c39-af70-1001dfe946d6", <br />
"locationRef": "http://localhost/path/to/backup", <br />
"name": "snapshot", <br />
"parent_id": null, <br />
"size": null, <br />
"status": "COMPLETED", <br />
"updated": "2014-02-13T21:47:16"<br />
}<br />
]<br />
}<br />
</pre><br />
<br />
=== Internal API ===<br />
* No change in the internal api, only to the initial model creation code in the backup models.<br />
==== RPC API description====<br />
* No change<br />
<br />
=== Guest Agent ===<br />
* No Change</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/backup-metadata&diff=48634Trove/backup-metadata2014-04-14T16:11:33Z<p>Robert Myers: </p>
<hr />
<div>== Description ==<br />
This blueprint will add the datastore and version to the backups api response.<br />
<br />
== Justification/Benefits ==<br />
* This will allow filtering the backups list by datastore type (and version?) <br />
* Eventually allow the api to restrict which datastore a backup could be restored to. (mysql -> mysql) (redis -> redis) <br />
<br />
== Impacts ==<br />
<br />
=== Configuration === <br />
None<br />
<br />
=== Database ===<br />
* The backup table will need to have a foreign key to the Datastore Version table.<br />
* This will require a migration to add the foreign key to all existing records<br />
<br />
=== Public API ===<br />
* This will add the datastore type and version to the API Response<br />
* This will also add the ability to filter the backup list by datastore<br />
<br />
==== CLI interface====<br />
* This will add a single param to backup-list command '--datastore' to filter the list by that datastore <br />
<br />
==== ReST Part ====<br />
New backup list Response:<br />
<pre><br />
HTTP/1.1 200 OK<br />
Content-Type: application/json<br />
Via: 1.1 Repose (Repose/2.6.7)<br />
Content-Length: 663<br />
Date: Thu, 13 Feb 2014 21:47:16 GMT<br />
Server: Jetty(8.0.y.z-SNAPSHOT)<br />
<br />
{<br />
"backups": [<br />
{<br />
"created": "2014-02-13T21:47:16", <br />
"datastore": {<br />
"type": "mysql",<br />
"version": "5.5"<br />
}<br />
"description": "My Backup", <br />
"id": "014cfa93-fd0e-4e9d-871f-da8bb2eeee3e", <br />
"instance_id": "dcf2c32b-241d-4c39-af70-1001dfe946d6", <br />
"locationRef": "http://localhost/path/to/backup", <br />
"name": "snapshot", <br />
"parent_id": null, <br />
"size": null, <br />
"status": "COMPLETED", <br />
"updated": "2014-02-13T21:47:16"<br />
}<br />
]<br />
}<br />
</pre><br />
<br />
=== Internal API ===<br />
* Does this change any internal messages between API and Task Manager or Task Manager to Guest<br />
==== RPC API description====<br />
* Method name.<br />
* Method parameters.<br />
* Message type (cast/call).<br />
<br />
=== Guest Agent ===<br />
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/backup-metadata&diff=48619Trove/backup-metadata2014-04-14T15:30:27Z<p>Robert Myers: 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..."</p>
<hr />
<div>== Description ==<br />
Describe the purpose of the enhancement<br />
<br />
== Justification/Benefits ==<br />
* What is the driving force behind this change? <br />
* Does it allow for great flexibility? Stability? Security?<br />
<br />
== Impacts ==<br />
<br />
=== Configuration === <br />
* Does this impact any configuration files? If so, which ones?<br />
<br />
=== Database ===<br />
* Does this impact any existing tables? If so, which ones?<br />
* Are the changes forward and backward compatible? <br />
* Be sure to include the expected migration process<br />
<br />
=== Public API ===<br />
* Does this change any API that an end-user has access to?<br />
* Are there any exceptions in terms of consistency with other APIs?<br />
<br />
==== CLI interface====<br />
* How the command will look like?<br />
* Does it extends the already existed command interfaces ?<br />
<br />
==== ReST Part ====<br />
* Which HTTP methods added ?<br />
* Which routes were added/modified/extended?<br />
* How does the Request body look like?<br />
* How does the Response object look like?<br />
<br />
=== Internal API ===<br />
* Does this change any internal messages between API and Task Manager or Task Manager to Guest<br />
==== RPC API description====<br />
* Method name.<br />
* Method parameters.<br />
* Message type (cast/call).<br />
<br />
=== Guest Agent ===<br />
* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=47704Trove/MoveTroveGuest2014-04-03T21:49:18Z<p>Robert Myers: </p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
* A new top level olso.cfg for the troveguest will be added. (This should be a small subset of the values in trove.common.cfg)<br />
* The values in trove.common.cfg that are specifically for the guest will be removed.<br />
* It is possible that some configuration values will need to be added or duplicated. <br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
=== Internal API ===<br />
None<br />
<br />
=== Guest Agent ===<br />
# The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
# The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
# Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
# The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=47703Trove/MoveTroveGuest2014-04-03T21:41:48Z<p>Robert Myers: /* Guest Agent */</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
Configuration values should stay the same<br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
==== CLI interface====<br />
None<br />
<br />
==== ReST Part ====<br />
No Change<br />
<br />
=== Internal API ===<br />
No Change<br />
<br />
==== RPC API description====<br />
No Change<br />
<br />
=== Guest Agent ===<br />
# The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
# The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
# Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
# The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=47702Trove/MoveTroveGuest2014-04-03T21:41:00Z<p>Robert Myers: /* Guest Agent */</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
Configuration values should stay the same<br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
==== CLI interface====<br />
None<br />
<br />
==== ReST Part ====<br />
No Change<br />
<br />
=== Internal API ===<br />
No Change<br />
<br />
==== RPC API description====<br />
No Change<br />
<br />
=== Guest Agent ===<br />
1. The guest agent code will be moved to a top level module in the existing trove repository called 'troveguest'. <br />
2. The import statements will be changed from 'trove.guestagent' to 'troveguest' <br />
3. Some common code will need to be duplicated within the troveguest so that there are no dependancies on the trove core. (This should hopefully be minimal)<br />
4. The code that currently rsync's the code over to instances in development will be changed to just include the 'troveguest' module. (It is possible that another delivery method will be used, however that should probably be done in its own blueprint)</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/MoveTroveGuest&diff=47701Trove/MoveTroveGuest2014-04-03T21:32:37Z<p>Robert Myers: Created page with " == Description == Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level..."</p>
<hr />
<div><br />
== Description ==<br />
Currently the Trove Guest Agent code is contained in the trove module. This blueprint goal is to split the guest agent specific code into another top level module called 'troveguest'. This will eventually be split out completely into another repository, the first step is to refactor the code so it is no longer dependent on trove core. <br />
<br />
== Justification/Benefits ==<br />
* Simplify installation of the guest agent on instances.<br />
* Reduce the amount of code that is deployed on instances.<br />
* Lower the memory footprint of the guest agent by not importing unnecessary code from Trove core.<br />
<br />
== Impacts ==<br />
* The setup.cfg will need to setup the new module along with trove. See [https://github.com/openstack/horizon/blob/master/setup.cfg#L31 horizon] for an example.<br />
* An example setup.cfg for just packaging the guest agent will be added along with a build_guest.py helper script.<br />
* Some in flight reviews will have a difficult rebase. (Cores will also need to be careful to merge them in order to minimize impact)<br />
<br />
=== Configuration === <br />
Configuration values should stay the same<br />
<br />
=== Database ===<br />
None<br />
<br />
=== Public API ===<br />
None<br />
<br />
==== CLI interface====<br />
None<br />
<br />
==== ReST Part ====<br />
No Change<br />
<br />
=== Internal API ===<br />
No Change<br />
<br />
==== RPC API description====<br />
No Change<br />
<br />
=== Guest Agent ===<br />
* The code will be moved to another path and all import statements will be refactored.<br />
* A new method for deploying the guest agent to the instance will be explored.</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=40387Trove/incremental-backups2014-01-23T15:56:15Z<p>Robert Myers: /* Incremental Workflow */</p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. <br />
<br />
* Add 'parent_id' field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
</pre><br />
<br />
* Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
* Another full or incremental backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
* An api call is made to run an incremental backup (one new optional field: 'parent_id'):<br />
<pre><br />
POST /backups <br />
{'name': 'incremental-backup-name',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
* A entry in the backup table is created.<br />
* The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
* A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'backup_location': <location>,<br />
'parent': {<br />
'location': <parent location>,<br />
'checksum': <parent file checksum><br />
}<br />
}<br />
</pre><br />
<br />
GUEST:<br />
* Backup agent will be changed to accept a type passed in by the api.<br />
* A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
* After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup.<br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
* Check that the backup file exists and checksum matches.<br />
* Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
* Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
* Read the backup_info and select the correct restore logic by backup_type<br />
* Preform restore on all parents if they exist.<br />
* Preform restore on backup<br />
* Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=40386Trove/incremental-backups2014-01-23T15:53:58Z<p>Robert Myers: /* Incremental Workflow */</p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. <br />
<br />
* Add 'parent_id' field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
</pre><br />
<br />
* Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
* A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
* An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'name': 'incremental-backup-name',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
* A entry in the backup table is created.<br />
* The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
* A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'backup_location': <location>,<br />
'parent': {<br />
'location': <parent location>,<br />
'checksum': <parent file checksum><br />
}<br />
}<br />
</pre><br />
<br />
GUEST:<br />
* Backup agent will be changed to accept a type passed in by the api.<br />
* A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
* After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup.<br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
* Check that the backup file exists and checksum matches.<br />
* Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
* Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
* Read the backup_info and select the correct restore logic by backup_type<br />
* Preform restore on all parents if they exist.<br />
* Preform restore on backup<br />
* Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=40384Trove/incremental-backups2014-01-23T15:51:28Z<p>Robert Myers: /* Storing Metadata */</p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. <br />
<br />
* Add 'parent_id' field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
</pre><br />
<br />
* Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
* A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
* An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
* A entry in the backup table is created.<br />
* The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
* A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'backup_location': <location>}<br />
</pre><br />
<br />
GUEST:<br />
* Backup agent will be changed to accept a type passed in by the api.<br />
* A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
* After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
* Check that the backup file exists and checksum matches.<br />
* Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
* Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
* Read the backup_info and select the correct restore logic by backup_type<br />
* Preform restore on all parents if they exist.<br />
* Preform restore on backup<br />
* Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Meetings/TroveMeeting&diff=36682Meetings/TroveMeeting2013-11-27T17:55:34Z<p>Robert Myers: /* Agenda for the next meeting */</p>
<hr />
<div><br />
= Weekly Trove (DBaaS) team meeting =<br />
<br />
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.<br />
<br />
== Agenda for the next meeting ==<br />
* Use jinja for guest agent configuration (rmyers)<br />
* Old Version History in gerrit (HOW DID I NOT KNOW ABOUT THIS?!?!)<br />
* Moving the reference guest into its own repo.<br />
* Party and Profit<br />
* Update reddwarft job without envolving -infra to add ability to launch custom test groups (denis_makogon)<br />
** cassandra<br />
** mongo<br />
** redis<br />
** postgresql<br />
* Ability to choose config.template by datastore version (denis_makogon)</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=36045Trove/incremental-backups2013-11-20T16:04:03Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
* Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
ADD COLUMN `automated` tinyint(1) DEFAULT 0;<br />
</pre><br />
<br />
: PROs: More secure as the data will be stored only in trove database.<br />
<br />
: CONs: The meta data will need to be passed to and from the guest, making the logic more complex.<br />
<br />
* Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
: PROs: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
<br />
: CONs: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
* A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
* An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
* A entry in the backup table is created.<br />
* The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
* A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'backup_location': <location>}<br />
</pre><br />
<br />
GUEST:<br />
* Backup agent will be changed to accept a type passed in by the api.<br />
* A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
* After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
* Check that the backup file exists and checksum matches.<br />
* Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
* Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
* Read the backup_info and select the correct restore logic by backup_type<br />
* Preform restore on all parents if they exist.<br />
* Preform restore on backup<br />
* Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=36044Trove/incremental-backups2013-11-20T16:02:23Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
* Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
ADD COLUMN `automated` tinyint(1) DEFAULT 0;<br />
</pre><br />
<br />
: PROs: More secure as the data will be stored only in trove database.<br />
<br />
: CONs: The meta data will need to be passed to and from the guest, making the logic more complex.<br />
<br />
* Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
: PROs: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
<br />
: CONs: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
* A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
* An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
* A entry in the backup table is created.<br />
* The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
* A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'parent_location': <parent_location>,<br />
'parent_id': <parent_id>}<br />
</pre><br />
<br />
GUEST:<br />
* Backup agent will be changed to accept a type passed in by the api.<br />
* A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
* After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
* Check that the backup file exists and checksum matches.<br />
* Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
* Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
* Read the backup_info and select the correct restore logic by backup_type<br />
* Preform restore on all parents if they exist.<br />
* Preform restore on backup<br />
* Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=36043Trove/incremental-backups2013-11-20T16:01:11Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
* Add meta field to the backups table in trove:<br />
<br />
: <pre><br />
: ALTER TABLE `backups`<br />
: ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
: ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
: ADD COLUMN `automated` tinyint(1) DEFAULT 0;<br />
: </pre><br />
<br />
PROs: More secure as the data will be stored only in trove database.<br />
<br />
CONs: The meta data will need to be passed to and from the guest, making the logic more complex.<br />
<br />
* Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
PROs: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
<br />
CONs: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
* A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
* An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
* A entry in the backup table is created.<br />
* The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
* A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'parent_location': <parent_location>,<br />
'parent_id': <parent_id>}<br />
</pre><br />
<br />
GUEST:<br />
* Backup agent will be changed to accept a type passed in by the api.<br />
* A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
* After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
* Check that the backup file exists and checksum matches.<br />
* Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
* Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
* Read the backup_info and select the correct restore logic by backup_type<br />
* Preform restore on all parents if they exist.<br />
* Preform restore on backup<br />
* Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=36042Trove/incremental-backups2013-11-20T15:58:12Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
# Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
ADD COLUMN `automated` tinyint(1) DEFAULT 0;<br />
</pre><br />
<br />
* PRO: More secure as the data will be stored only in trove database.<br />
* CON: The meta data will need to be passed to and from the guest, making the logic more complex.<br />
<br />
# Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
* PRO: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
* CON: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
# A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
# An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
# A entry in the backup table is created.<br />
# The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
# A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'parent_location': <parent_location>,<br />
'parent_id': <parent_id>}<br />
</pre><br />
<br />
GUEST:<br />
# Backup agent will be changed to accept a type passed in by the api.<br />
# A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s /var/lib/mysql<br />
</pre><br />
# After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
# Check that the backup file exists and checksum matches.<br />
# Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
# Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
# Read the backup_info and select the correct restore logic by backup_type<br />
# Preform restore on all parents if they exist.<br />
# Preform restore on backup<br />
# Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=36041Trove/incremental-backups2013-11-20T15:55:12Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
# 1 Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
ADD COLUMN `automated` tinyint(1) DEFAULT 0;<br />
</pre><br />
<br />
* PRO: More secure as the data will be stored only in trove database.<br />
* CON: The meta data will need to be passed to and from the guest, making the logic more complex.<br />
<br />
# 2. Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
* PRO: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
* CON: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
# 1. A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
# 2. An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
# 3. A entry in the backup table is created.<br />
# 4. The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
# 5. A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'parent_location': <parent_location>,<br />
'parent_id': <parent_id>}<br />
</pre><br />
<br />
GUEST:<br />
# 1. backup agent will be changed to accept a type passed in by the api.<br />
# 2. A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s<br />
</pre><br />
# 3. After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
# 1. Check that the backup file exists and checksum matches.<br />
# 2. Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
# 3. Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
# 1. Read the backup_info and select the correct restore logic by backup_type<br />
# 2. Preform restore on all parents if they exist.<br />
# 3. Preform restore on backup<br />
# 4. Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=36040Trove/incremental-backups2013-11-20T15:52:13Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
1. Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
ADD COLUMN `parent_id` varchar(36) DEFAULT NULL;<br />
ADD COLUMN `automated` tinyint(1) DEFAULT 0;<br />
</pre><br />
<br />
* PRO: More secure as the data will be stored only in trove database.<br />
* CON: The meta data will need to be passed to and from the guest, making the logic more complex.<br />
<br />
2. Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
-H "X-Object-Meta-LSN: 123456789" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
* PRO: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
* CON: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
1. A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
2. An api call is made to run an incremental backup (two new optional fields):<br />
<pre><br />
POST /backups <br />
{'backup_type': 'incremental',<br />
'instance_id': 'instance_id',<br />
'parent_id': '<parent_id>'}<br />
</pre><br />
3. A entry in the backup table is created.<br />
4. The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
5. A message is sent to the guest to run the backup<br />
<pre><br />
backup_info = {<br />
'backup_type': 'incremental',<br />
'meta': <meta_info_from_parent>,<br />
'parent_location': <parent_location>,<br />
'parent_id': <parent_id>}<br />
</pre><br />
<br />
GUEST:<br />
1. backup agent will be changed to accept a type passed in by the api.<br />
2. A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s<br />
</pre><br />
3. After a successful backup record meta data along with other backup info (location, checksum, etc) For xtrabackup that will include the last LSN number of the backup. <br />
<br />
=== Full backup changes (innobackupex) ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<pre><br />
def check_process():<br />
# check for 'completed OK!'<br />
# parse out the LSN number<br />
# update meta data property on backup<br />
return True<br />
</pre><br />
<br />
=== Restore Workflow (metadata in db) ===<br />
<br />
During the create instance call if a backup ID is passed in restorePoint the api will need to change slightly:<br />
<br />
API:<br />
1. Check that the backup file exists and checksum matches.<br />
2. Check if the backup has a parent<br />
a. Check that parent exists/checksum matches and add to the backup_info object<br />
b. Check if the parent backup has a parent and repeat<br />
3. Send the backup_info to the guest to do the restore.<br />
<br />
GUEST:<br />
1. Read the backup_info and select the correct restore logic by backup_type<br />
2. Preform restore on all parents if they exist.<br />
3. Preform restore on backup<br />
4. Finish guest install</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=35906Trove/incremental-backups2013-11-19T22:06:26Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
1. Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
</pre><br />
<br />
* PRO: More secure as the data will be stored only in trove database.<br />
* CON: The meta data will need to be passed to and from the guest, making the logic more conplex.<br />
<br />
2. Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
* PRO: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
* CON: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
API:<br />
<br />
1. A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
2. An api call is made to run an incremental backup:<br />
<pre>POST /backups {'backup_type': 'incremental', 'instance_id': 'instance_id', 'parent_id': '<parent_id>'}</pre><br />
3. A entry in the backup table is created.<br />
4. The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
5. A message is sent to the guest to run the backup<br />
<pre>backup_info = {'backup_type': 'incremental', 'meta': <meta_info_from_parent>, 'parent_location': <parent_location>, 'parent_id': <parent_id>}</pre><br />
<br />
GUEST:<br />
1. backup agent will be changed to accept a type passed in by the api.<br />
2. A new backup type of increamental uses the meta data to preform the restore. For xtrabackup this requires passing a 'lsn' number to the backup command:<br />
<pre><br />
/usr/bin/innobackupex --stream --ibbackup=xtrabackup \<br />
--incremental --incremental-lsn=%(lsn)s<br />
</pre><br />
3. After a successful backup.<br />
<br />
=== Full backup changes ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<br />
=== Optional Point in Time Restore API ===<br />
<br />
This will require modifying the existing restorePoint object for the create instance call. The api will be expanded to:<br />
<br />
<pre><br />
restorePoint = {<br />
instance = 'uuid_of_instance'<br />
time = 'date string'<br />
}<br />
</pre></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=35904Trove/incremental-backups2013-11-19T21:52:05Z<p>Robert Myers: </p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
https://wiki.openstack.org/wiki/Trove/scheduled-tasks<br />
<br />
=== Storing Metadata===<br />
<br />
In order to create incremental backups we need to store a little extra information in full backups and incremental ones. There are two options for storing this metadata for the incremental and full backups.<br />
<br />
1. Add meta field to the backups table in trove:<br />
<br />
<pre><br />
ALTER TABLE `backups`<br />
ADD COLUMN `meta` varchar(1024) DEFAULT NULL;<br />
</pre><br />
<br />
* PRO: More secure as the data will be stored only in trove database.<br />
* CON: The meta data will need to be passed to and from the guest, making the logic more conplex.<br />
<br />
2. Use swift metadata http://docs.openstack.org/api/openstack-object-storage/1.0/content/object-metadata.html to store any extra metadata for the backup.<br />
<br />
<pre><br />
curl –X POST -i \<br />
-H "X-Auth-Token: my-token" \<br />
-H "X-Object-Meta-Parent: https://storage.com/v1/XXX/path_to_parent_backup"" \<br />
https://storage.com/v1/XXX/path_to_incremental_backup<br />
</pre><br />
<br />
* PRO: No database change. No need to pass extra info to the guest as a simple HEAD call on the swift file will get the meta info. The guest can easily update the metadata on the swift objects it writes.<br />
* CON: Less secure as users can change these fields (possibly this field could be encrypted with the same key as the backups)<br />
<br />
=== Incremental Workflow ===<br />
<br />
1. A full backup must be made by the user or an automated system. (This backup ID is used as the parent ID)<br />
2. An api call is made to run an incremental backup:<br />
<pre>POST /backups {'backup_type': 'incremental', 'instance_id': 'instance_id', 'parent_id': '<parent_id>'}</pre><br />
3. A entry in the backup table is created.<br />
4. The backup handler looks up the information on the parent backup (error if it doesn't exist)<br />
5. A message is sent to the guest to run the backup<br />
<pre>backup_info = {'backup_type': 'incremental', 'meta': <meta_info_from_parent>, 'parent_location': <parent_location>, 'parent_id': <parent_id>}<pre><br />
<br />
=== Full backup changes ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<br />
=== Optional Point in Time Restore API ===<br />
<br />
This will require modifying the existing restorePoint object for the create instance call. The api will be expanded to:<br />
<br />
<pre><br />
restorePoint = {<br />
instance = 'uuid_of_instance'<br />
time = 'date string'<br />
}<br />
</pre></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=33615Trove/incremental-backups2013-10-22T19:02:25Z<p>Robert Myers: /* Incremental Backups */</p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores. The main difference between this and the current manual backups will be that these will be deleted when the instance is deleted. This is intended to be run as a backend scheduled task. <br />
<br />
=== Database Changes ===<br />
<br />
It is necessary to add a text field to store meta data from the backups. This includes the type of backup and the position of the bin logs or lsn number.<br />
<br />
Table Backup - add meta text field null true<br />
<br />
=== Full backup changes ===<br />
<br />
Change the current backup process to add the meta data from the backup process.<br />
<br />
<br />
=== Restore incremental backup call ===<br />
<br />
This will require modifying the existing restorePoint object for the create instance call. The api will be expanded to:<br />
<br />
<pre><br />
restorePoint = {<br />
instance = 'uuid_of_instance'<br />
time = 'date string'<br />
}<br />
</pre></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Trove/incremental-backups&diff=33608Trove/incremental-backups2013-10-22T18:51:02Z<p>Robert Myers: Created page with "== Incremental Backups == Adding support for incremental backups and restores. === Database Changes === It is necessary to add a text field to store meta data from the back..."</p>
<hr />
<div>== Incremental Backups ==<br />
<br />
Adding support for incremental backups and restores.<br />
<br />
=== Database Changes ===<br />
<br />
It is necessary to add a text field to store meta data from the backups. This includes the type of backup and the position of the bin logs or lsn number.<br />
<br />
Table Backup - add meta text field null true<br />
<br />
=== Full backup changes ===<br />
<br />
Change the current backup process to add the meta data from the backup process.</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28945Horizon/trove-support2013-08-27T19:08:20Z<p>Robert Myers: </p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support. Currently the panels are only displayed if you have trove installed and your service catalog contains 'database'.<br />
<br />
Database Backup panels also require that you have 'object-store' in your service catalog as well.<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Trove Install Instructions ===<br />
<br />
Trove is currently not installable with just devstack alone. The Trove team maintains a separate repo to install that uses devstack: <br />
<br />
https://wiki.openstack.org/wiki/Trove/installation<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|Launch Instance]]<br />
<br />
[[File:horizon_launch_database_initialize.png|Launch Instance - Initialize]]<br />
<br />
[[File:horizon_launch_database_restore.png|Launch Instance - Restore]]<br />
<br />
[[File:horizon_launching_database.png|Launching Instance - Ajax]]<br />
<br />
==== Database Index ====<br />
<br />
[[File:horizon_database_list.png|Database Index]]<br />
<br />
==== Database Details ====<br />
<br />
[[File:horizon_database_details.png|Database Details]]<br />
<br />
[[File:horizon_database_details_users.png|Database Details - Users]]<br />
<br />
[[File:horizon_database_details_databases.png|Database Details - Databases]]<br />
<br />
[[File:horizon_database_details_backups.png|Database Details - Backups]]<br />
<br />
==== Create Database Backup====<br />
<br />
[[File:horizon_create_database_backup.png|Create Backup]]<br />
<br />
[[File:horizon_creating_database_backup.png|Create Backup - Ajax]]<br />
<br />
==== Database Backup Index ====<br />
<br />
[[File:horizon_database_backups_index.png|Database Backup Index]]<br />
<br />
==== Database Backup Details ====<br />
<br />
[[File:horizon_database_backup_details.png|Database Backup Details]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28720Horizon/trove-support2013-08-23T17:16:10Z<p>Robert Myers: /* Trove Support */</p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support. Currently the panels are only displayed if you have trove installed and your service catalog contains 'database'.<br />
<br />
Database Backup panels also require that you have 'object-store' in your service catalog as well.<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|Launch Instance]]<br />
<br />
[[File:horizon_launch_database_initialize.png|Launch Instance - Initialize]]<br />
<br />
[[File:horizon_launch_database_restore.png|Launch Instance - Restore]]<br />
<br />
[[File:horizon_launching_database.png|Launching Instance - Ajax]]<br />
<br />
==== Database Index ====<br />
<br />
[[File:horizon_database_list.png|Database Index]]<br />
<br />
==== Database Details ====<br />
<br />
[[File:horizon_database_details.png|Database Details]]<br />
<br />
[[File:horizon_database_details_users.png|Database Details - Users]]<br />
<br />
[[File:horizon_database_details_databases.png|Database Details - Databases]]<br />
<br />
[[File:horizon_database_details_backups.png|Database Details - Backups]]<br />
<br />
==== Create Database Backup====<br />
<br />
[[File:horizon_create_database_backup.png|Create Backup]]<br />
<br />
[[File:horizon_creating_database_backup.png|Create Backup - Ajax]]<br />
<br />
==== Database Backup Index ====<br />
<br />
[[File:horizon_database_backups_index.png|Database Backup Index]]<br />
<br />
==== Database Backup Details ====<br />
<br />
[[File:horizon_database_backup_details.png|Database Backup Details]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_details.png&diff=28717File:Horizon database details.png2013-08-23T17:12:17Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28715Horizon/trove-support2013-08-23T17:11:48Z<p>Robert Myers: </p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|Launch Instance]]<br />
<br />
[[File:horizon_launch_database_initialize.png|Launch Instance - Initialize]]<br />
<br />
[[File:horizon_launch_database_restore.png|Launch Instance - Restore]]<br />
<br />
[[File:horizon_launching_database.png|Launching Instance - Ajax]]<br />
<br />
==== Database Index ====<br />
<br />
[[File:horizon_database_list.png|Database Index]]<br />
<br />
==== Database Details ====<br />
<br />
[[File:horizon_database_details.png|Database Details]]<br />
<br />
[[File:horizon_database_details_users.png|Database Details - Users]]<br />
<br />
[[File:horizon_database_details_databases.png|Database Details - Databases]]<br />
<br />
[[File:horizon_database_details_backups.png|Database Details - Backups]]<br />
<br />
==== Create Database Backup====<br />
<br />
[[File:horizon_create_database_backup.png|Create Backup]]<br />
<br />
[[File:horizon_creating_database_backup.png|Create Backup - Ajax]]<br />
<br />
==== Database Backup Index ====<br />
<br />
[[File:horizon_database_backups_index.png|Database Backup Index]]<br />
<br />
==== Database Backup Details ====<br />
<br />
[[File:horizon_database_backup_details.png|Database Backup Details]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28712Horizon/trove-support2013-08-23T17:10:26Z<p>Robert Myers: </p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|Launch Instance]]<br />
[[File:horizon_launch_database_initialize.png|Launch Instance - Initialize]]<br />
[[File:horizon_launch_database_restore.png|Launch Instance - Restore]]<br />
[[File:horizon_launching_database.png|Launching Instance - Ajax]]<br />
<br />
==== Database Index ====<br />
<br />
[[File:horizon_database_list.png|Database Index]]<br />
<br />
==== Database Details ====<br />
<br />
[[File:horizon_database_details.png|framed|Database Details]<br />
[[File:horizon_database_details_users.png|framed|Database Details - Users]]<br />
[[File:horizon_database_details_databases.png|framed|Database Details - Databases]]<br />
[[File:horizon_database_details_backups.png|framed|Database Details - Backups]]<br />
<br />
==== Create Database Backup====<br />
<br />
[[File:horizon_create_database_backup.png|framed|Create Backup]]<br />
[[File:horizon_creating_database_backup.png|framed|Create Backup - Ajax]]<br />
<br />
==== Database Backup Index ====<br />
<br />
[[File:horizon_database_backups_index.png|framed|Database Backup Index]]<br />
<br />
==== Database Backup Details ====<br />
<br />
[[File:horizon_database_backup_details.png|framed|Database Backup Details]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_backup_details.png&diff=28711File:Horizon database backup details.png2013-08-23T17:09:34Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_backups_index.png&diff=28710File:Horizon database backups index.png2013-08-23T17:09:10Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_creating_database_backup.png&diff=28708File:Horizon creating database backup.png2013-08-23T17:08:41Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_create_database_backup.png&diff=28707File:Horizon create database backup.png2013-08-23T17:08:16Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_details_backups.png&diff=28706File:Horizon database details backups.png2013-08-23T17:07:44Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_details_databases.png&diff=28705File:Horizon database details databases.png2013-08-23T17:07:09Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_details_users.png&diff=28703File:Horizon database details users.png2013-08-23T17:06:43Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_database_list.png&diff=28702File:Horizon database list.png2013-08-23T17:06:09Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_launching_database.png&diff=28699File:Horizon launching database.png2013-08-23T17:04:24Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28697Horizon/trove-support2013-08-23T17:04:02Z<p>Robert Myers: </p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|framed|Launch Instance]]<br />
[[File:horizon_launch_database_initialize.png|framed|Launch Instance - Initialize]]<br />
[[File:horizon_launch_database_restore.png|framed|Launch Instance - Restore]]<br />
[[File:horizon_launching_database.png|framed|Launching Instance - Ajax]]<br />
<br />
==== Database Index ====<br />
<br />
[[File:horizon_database_list.png|framed|Database Index]]<br />
<br />
==== Database Details ====<br />
<br />
[[File:horizon_database_details.png|framed|Database Details]<br />
[[File:horizon_database_details_users.png|framed|Database Details - Users]]<br />
[[File:horizon_database_details_databases.png|framed|Database Details - Databases]]<br />
[[File:horizon_database_details_backups.png|framed|Database Details - Backups]]<br />
<br />
==== Create Database Backup====<br />
<br />
[[File:horizon_create_database_backup.png|framed|Create Backup]]<br />
[[File:horizon_creating_database_backup.png|framed|Create Backup - Ajax]]<br />
<br />
==== Database Backup Index ====<br />
<br />
[[File:horizon_database_backups_index.png|framed|Database Backup Index]]<br />
<br />
==== Database Backup Details ====<br />
<br />
[[File:horizon_database_backup_details.png|framed|Database Backup Details]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_launch_database_restore.png&diff=28692File:Horizon launch database restore.png2013-08-23T16:51:17Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_launch_database_initialize.png&diff=28691File:Horizon launch database initialize.png2013-08-23T16:50:51Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28690Horizon/trove-support2013-08-23T16:50:31Z<p>Robert Myers: /* Creating Database instances */</p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|framed|Launch Instance]]<br />
[[File:horizon_launch_database_initialize.png|framed|Launch Instance - Initialize]]<br />
[[File:horizon_launch_database_restore.png|framed|Launch Instance - Restore]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=Horizon/trove-support&diff=28688Horizon/trove-support2013-08-23T16:48:53Z<p>Robert Myers: /* Creating Database instances */</p>
<hr />
<div>== Trove Support ==<br />
<br />
Adding panels for trove support<br />
<br />
=== Gerrit Review ===<br />
<br />
https://review.openstack.org/#/c/42228/<br />
<br />
=== Screen Shots ===<br />
<br />
==== Creating Database instances ====<br />
<br />
[[File:horizon_launch_database_main.png|framed|Launch Instance]]</div>Robert Myershttps://wiki.openstack.org/w/index.php?title=File:Horizon_launch_database_main.png&diff=28687File:Horizon launch database main.png2013-08-23T16:48:04Z<p>Robert Myers: </p>
<hr />
<div></div>Robert Myers