Trove/backup-metadata - Revision history

Amcrn: /* Comments/Questions From Community */

2014-04-24T06:05:50Z

‎Comments/Questions From Community

Daniel Morris: /* Comments/Questions From Community */

2014-04-23T20:20:47Z

‎Comments/Questions From Community

Daniel Morris: /* Comments/Questions From Community */

2014-04-23T20:20:28Z

‎Comments/Questions From Community

Amcrn at 17:21, 15 April 2014

2014-04-15T17:21:46Z

Robert Myers: /* Description */

2014-04-14T16:20:57Z

‎Description

Robert Myers: /* ReST Part */

2014-04-14T16:15:38Z

‎ReST Part

Robert Myers at 16:13, 14 April 2014

2014-04-14T16:13:12Z

Robert Myers at 16:11, 14 April 2014

2014-04-14T16:11:33Z

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

2014-04-14T15:30:27Z

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

New page

== Description ==
Describe the purpose of the enhancement

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

== Impacts ==

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

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

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

==== CLI interface====
* How the command will look like?
* Does it extends the already existed command interfaces ?

==== ReST Part ====
* Which HTTP methods added ?
* Which routes were added/modified/extended?
* How does the Request body look like?
* How does the Response object look like?

=== Internal API ===
* Does this change any internal messages between API and Task Manager or Task Manager to Guest
==== RPC API description====
* Method name.
* Method parameters.
* Message type (cast/call).

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

@@ Line 97: / Line 97: @@
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): datastore-type and datastore-version information should be returned for backup-instance-list in addition to backup-list and backup-show.
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): given in the near future an instance can be upgraded via the api from datastore-version 'x' to datastore-version 'y', it makes sense that the datastore-type and datastore-version are returned in backup-list-instance, as well as backup-show and backup-list. what's not immediately clear to me is why someone would want to filter a backup-list by datastore or datastore-version? can you provide a use-case?
-* --[[User:Daniel Morris|Daniel Morris]] ([[User talk:Daniel Morris|talk]]) 20:20, 23 April 2014 (UTC)Think about the case of a UI and optimizing the UX experience when there are multiple datastores and types.  If I am a MySQL instance vs. a Redis instance.  When I am in the context of Redis, I want to only see the backps for Redis, and when i am working with MySQL, I only want to see the backups for MySQL.   The same applies for Restores.  It allows you to filter and or create facet's based on the datastore / version context you are working under.  (E.g. preventing users from inadvertently attempting to restore a MySQL backup to a Redis instance.)
+** --[[User:Daniel Morris|Daniel Morris]] ([[User talk:Daniel Morris|talk]]) 20:20, 23 April 2014 (UTC)Think about the case of a UI and optimizing the UX experience when there are multiple datastores and types.  If I am a MySQL instance vs. a Redis instance.  When I am in the context of Redis, I want to only see the backps for Redis, and when i am working with MySQL, I only want to see the backups for MySQL.   The same applies for Restores.  It allows you to filter and or create facet's based on the datastore / version context you are working under.  (E.g. preventing users from inadvertently attempting to restore a MySQL backup to a Redis instance.)
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): as it stands today, a datastore-version is tied to a manager, and a manager has an optgroup. in the near future, backup_strategy and restore_strategy will be moved from the DEFAULT optgroup to a manager-specific optgroup (see https://review.openstack.org/#/c/77899/11/etc/trove/trove-guestagent.conf.sample). this indirectly means that a manager has an associated backup/restore_strategy. since the cloud provider has the ability to change the backup/restore_strategy at any time, the manager name isn't enough information to know whether the backup can be restored to a specific datastore-version. therefore, the backup and restore strategies must be stored in the backup table. the datastore-version should also be stored because a datastore might use the exact same commands (aka same manager impl) to create a backup for version 'x' as compared to version 'y', but the output for 'x' might be incompatible for import into 'y' (maybe the underlying data arrangement/packing changed, etc.). Without being an expert in all datastore's backup limitations across major and minor versions, it's difficult to guess whether the backup/restore_strategy code changes often. one thing is certain however, recording more information is always better than not having enough. note: for now, backup/restore_strategy in this scenario would not be returned in show/list calls.

@@ Line 97: / Line 97: @@
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): datastore-type and datastore-version information should be returned for backup-instance-list in addition to backup-list and backup-show.
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): given in the near future an instance can be upgraded via the api from datastore-version 'x' to datastore-version 'y', it makes sense that the datastore-type and datastore-version are returned in backup-list-instance, as well as backup-show and backup-list. what's not immediately clear to me is why someone would want to filter a backup-list by datastore or datastore-version? can you provide a use-case?
---[[User:Daniel Morris|Daniel Morris]] ([[User talk:Daniel Morris|talk]]) 20:20, 23 April 2014 (UTC)Think about the case of a UI and optimizing the UX experience when there are multiple datastores and types.  If I am a MySQL instance vs. a Redis instance.  When I am in the context of Redis, I want to only see the backps for Redis, and when i am working with MySQL, I only want to see the backups for MySQL.   The same applies for Restores.  It allows you to filter and or create facet's based on the datastore / version context you are working under.  (E.g. preventing users from inadvertently attempting to restore a MySQL backup to a Redis instance.)
+* --[[User:Daniel Morris|Daniel Morris]] ([[User talk:Daniel Morris|talk]]) 20:20, 23 April 2014 (UTC)Think about the case of a UI and optimizing the UX experience when there are multiple datastores and types.  If I am a MySQL instance vs. a Redis instance.  When I am in the context of Redis, I want to only see the backps for Redis, and when i am working with MySQL, I only want to see the backups for MySQL.   The same applies for Restores.  It allows you to filter and or create facet's based on the datastore / version context you are working under.  (E.g. preventing users from inadvertently attempting to restore a MySQL backup to a Redis instance.)
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): as it stands today, a datastore-version is tied to a manager, and a manager has an optgroup. in the near future, backup_strategy and restore_strategy will be moved from the DEFAULT optgroup to a manager-specific optgroup (see https://review.openstack.org/#/c/77899/11/etc/trove/trove-guestagent.conf.sample). this indirectly means that a manager has an associated backup/restore_strategy. since the cloud provider has the ability to change the backup/restore_strategy at any time, the manager name isn't enough information to know whether the backup can be restored to a specific datastore-version. therefore, the backup and restore strategies must be stored in the backup table. the datastore-version should also be stored because a datastore might use the exact same commands (aka same manager impl) to create a backup for version 'x' as compared to version 'y', but the output for 'x' might be incompatible for import into 'y' (maybe the underlying data arrangement/packing changed, etc.). Without being an expert in all datastore's backup limitations across major and minor versions, it's difficult to guess whether the backup/restore_strategy code changes often. one thing is certain however, recording more information is always better than not having enough. note: for now, backup/restore_strategy in this scenario would not be returned in show/list calls.

@@ Line 97: / Line 97: @@
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): datastore-type and datastore-version information should be returned for backup-instance-list in addition to backup-list and backup-show.
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): given in the near future an instance can be upgraded via the api from datastore-version 'x' to datastore-version 'y', it makes sense that the datastore-type and datastore-version are returned in backup-list-instance, as well as backup-show and backup-list. what's not immediately clear to me is why someone would want to filter a backup-list by datastore or datastore-version? can you provide a use-case?
 * [[User:Amcrn|amcrn]] ([[User talk:Amcrn|talk]]) 17:21, 15 April 2014 (UTC): as it stands today, a datastore-version is tied to a manager, and a manager has an optgroup. in the near future, backup_strategy and restore_strategy will be moved from the DEFAULT optgroup to a manager-specific optgroup (see https://review.openstack.org/#/c/77899/11/etc/trove/trove-guestagent.conf.sample). this indirectly means that a manager has an associated backup/restore_strategy. since the cloud provider has the ability to change the backup/restore_strategy at any time, the manager name isn't enough information to know whether the backup can be restored to a specific datastore-version. therefore, the backup and restore strategies must be stored in the backup table. the datastore-version should also be stored because a datastore might use the exact same commands (aka same manager impl) to create a backup for version 'x' as compared to version 'y', but the output for 'x' might be incompatible for import into 'y' (maybe the underlying data arrangement/packing changed, etc.). Without being an expert in all datastore's backup limitations across major and minor versions, it's difficult to guess whether the backup/restore_strategy code changes often. one thing is certain however, recording more information is always better than not having enough. note: for now, backup/restore_strategy in this scenario would not be returned in show/list calls.

← Older revision		Revision as of 17:21, 15 April 2014
Line 92:		Line 92:
	=== Guest Agent ===		=== Guest Agent ===
	* No Change		* No Change
		+
		+	== Comments/Questions From Community ==
		+
		+	* [[User:Amcrn\|amcrn]] ([[User talk:Amcrn\|talk]]) 17:21, 15 April 2014 (UTC): datastore-type and datastore-version information should be returned for backup-instance-list in addition to backup-list and backup-show.
		+	* [[User:Amcrn\|amcrn]] ([[User talk:Amcrn\|talk]]) 17:21, 15 April 2014 (UTC): given in the near future an instance can be upgraded via the api from datastore-version 'x' to datastore-version 'y', it makes sense that the datastore-type and datastore-version are returned in backup-list-instance, as well as backup-show and backup-list. what's not immediately clear to me is why someone would want to filter a backup-list by datastore or datastore-version? can you provide a use-case?
		+	* [[User:Amcrn\|amcrn]] ([[User talk:Amcrn\|talk]]) 17:21, 15 April 2014 (UTC): as it stands today, a datastore-version is tied to a manager, and a manager has an optgroup. in the near future, backup_strategy and restore_strategy will be moved from the DEFAULT optgroup to a manager-specific optgroup (see https://review.openstack.org/#/c/77899/11/etc/trove/trove-guestagent.conf.sample). this indirectly means that a manager has an associated backup/restore_strategy. since the cloud provider has the ability to change the backup/restore_strategy at any time, the manager name isn't enough information to know whether the backup can be restored to a specific datastore-version. therefore, the backup and restore strategies must be stored in the backup table. the datastore-version should also be stored because a datastore might use the exact same commands (aka same manager impl) to create a backup for version 'x' as compared to version 'y', but the output for 'x' might be incompatible for import into 'y' (maybe the underlying data arrangement/packing changed, etc.). Without being an expert in all datastore's backup limitations across major and minor versions, it's difficult to guess whether the backup/restore_strategy code changes often. one thing is certain however, recording more information is always better than not having enough. note: for now, backup/restore_strategy in this scenario would not be returned in show/list calls.

@@ Line 23: / Line 23: @@
 ==== ReST Part ====
-New backup list Response:
+==== New backup list Response: ====
 <pre>
 HTTP/1.1 200 OK
@@ Line 51: / Line 51: @@
+         }
+     ]
+}
 </pre>

@@ Line 1: / Line 1: @@
 == Description ==
 This blueprint will add the datastore and version to the backups api response.
 == Justification/Benefits ==

@@ Line 55: / Line 55: @@
 === Internal API ===
-* Does this change any internal messages between API and Task Manager or Task Manager to Guest
+* No change in the internal api, only to the initial model creation code in the backup models.
 ==== RPC API description====
-* Method name.
+* No change
 === Guest Agent ===
-* Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?
+* No Change

@@ Line 1: / Line 1: @@
 == Description ==
-Describe the purpose of the enhancement
+This blueprint will add the datastore and version to the backups api response.
 == Justification/Benefits ==
-* What is the driving force behind this change?
+* This will allow filtering the backups list by datastore type (and version?)
-* Does it allow for great flexibility? Stability? Security?
+* Eventually allow the api to restrict which datastore a backup could be restored to. (mysql -> mysql) (redis -> redis)
 == Impacts ==
 === Configuration ===
-* Does this impact any configuration files? If so, which ones?
+None
 === Database ===
-* Does this impact any existing tables?  If so, which ones?
+* The backup table will need to have a foreign key to the Datastore Version table.
-* Are the changes forward and backward compatible?
+* This will require a migration to add the foreign key to all existing records
 === Public API ===
-* Does this change any API that an end-user has access to?
+* This will add the datastore type and version to the API Response
-* Are there any exceptions in terms of consistency with other APIs?
+* This will also add the ability to filter the backup list by datastore
 ==== CLI interface====
-* How the command will look like?
+* This will add a single param to backup-list command '--datastore' to filter the list by that datastore
 ==== ReST Part ====
-* Which HTTP methods added ?
+New backup list Response:
-* Which routes were added/modified/extended?
+<pre>
-* How does the Request body look like?
+HTTP/1.1 200 OK
-* How does the Response object look like?
+Content-Type: application/json
 === Internal API ===