Difference between revisions of "Trove/OpenstackClient"

Revision as of 19:00, 18 November 2015

Trove OpenStack Client Plugin Migration

This wiki page is intended to design how the commands for trove will look when we do the migration to the OpenStack client. Given that we don't have backwards compatibility issues this is a good opportunity to look at the usability of our commands and improve the user experience.

Existing pain points for Python-TroveClient

Inconsistency between name and id use across commands
creating and updating configuration parameters is really hard. (not sure what a good solution is for this right now.)

Replication Group/Cluster

atomic77 - The distinction we maintain, internally, between replica groups and clusters should ideally be less apparent to a trove user. If we are not required to maintain a 1-1 mapping between the openstack client and the legacy trove client, perhaps it is an opportunity to present it that way, even if behind the scenes we still manage this differently. Why should a trove user know or care about why, say, percona-xe fully-replicated with 3 nodes is a "cluster", while traditional mysql/percona with two asynch slaves is a two step process to create a single node, then another create with --replica_of --replica_count 2?

So it could be something like

   openstack trove cluster-create .. --nodes 3 --topology {"multi-master", "async master/slave", etc}

Not clear how ambitious this would be especially if we don't want to make backend changes, but if we ever want to fix this, this is a great time to start.

Examples

Python-TroveClient	Python-OpenStackClient
backup-copy	Example
backup-create	Example
backup-delete	Example
backup-list	Example
backup-list-instance	Example
backup-show	Example
cluster-create	Example
cluster-delete	Example
cluster-instances	Example
cluster-list	Example
cluster-show	Example
configuration-attach	Example
configuration-create	Example
configuration-default	Example
configuration-delete	Example
configuration-detach	Example
configuration-instances	Example
configuration-list	Example
configuration-parameter-list	Example
configuration-parameter-show	Example
configuration-patch	Example
configuration-show	Example
configuration-update	Example
create	Example
database-create	Example
database-delete	Example
database-list	Example
datastore-list	Example
datastore-show	Example
datastore-version-list	Example
datastore-version-show	Example
delete	Example
detach-replica	Example
flavor-list	Example
flavor-show	Example
limit-list	Example
list	Example
metadata-create	Example
metadata-delete	Example
metadata-edit	Example
metadata-list	Example
metadata-show	Example
metadata-update	Example
resize-flavor	Example
resize-instance	Example
resize-volume	Example
restart	Example
root-enable	Example
root-show	Example
secgroup-add-rule	Example
secgroup-delete-rule	Example
secgroup-list	Example
secgroup-list-rules	Example
secgroup-show	Example
show	Example
update	Example
user-create	Example
user-delete	Example
user-grant-access	Example
user-list	Example
user-revoke-access	Example
user-show	Example
user-show-access	Example
user-update-attributes	Example
bash-completion	Example
help	Example

@@ Line 6: / Line 6: @@
 * Inconsistency between name and id use across commands
 * creating and updating configuration parameters is really hard. (not sure what a good solution is for this right now.)
+==== Replication Group/Cluster ====
+atomic77 - The distinction we maintain, internally, between replica groups and clusters should ideally be less apparent to a trove user. If we are not required to maintain a 1-1 mapping between the openstack client and the legacy trove client, perhaps it is an opportunity to present it that way, even if behind the scenes we still manage this differently. Why should a trove user know or care about why, say, percona-xe fully-replicated with 3 nodes is a "cluster", while traditional mysql/percona with two asynch slaves is a two step process to create a single node, then another create with --replica_of  --replica_count 2?
+So it could be something like
+    openstack trove cluster-create .. --nodes 3 --topology {"multi-master", "async master/slave", etc}
+Not clear how ambitious this would be especially if we don't want to make backend changes, but if we ever want to fix this, this is a great time to start.
 === Examples ===