Jump to: navigation, search

Trove/OpenstackClient

< Trove
Revision as of 20:44, 23 November 2015 by Amrith (talk | contribs) (Extensible CLI)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.)
  • No need for metadata
  • It would be useful to had a single call to get all datastores and versions in a merged list. (would require a new api call for this to happen though so it wouldnt be 1+(# of datastores) api cals.
  • Add the management api calls. (quota and reset status were called out)

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.

Extensible CLI

As atomic77 mentions above, one area where we have issues is in the distinction between instances and clusters. A more generic view of this is that the CLI for Trove is a very ambitious undertaking. Consider that the CLI needs to be able to provide commands that will address a variety of different databases, in a variety of different configurations. It should equally well be able to handle a single instance of MySQL, a cluster of MongoDB and a cluster of PXC (MySQL by another name). The CLI is also equally required to help to administer the back-end as well (Trove management commands).

As we have evolved the Trove capabilities, this has resulted in an inconsistent set of additions to the CLI.

In looking to migrate to the openstack CLI, I think we should give some consideration to the UX/UI for the CLI and attempt to create a set of commands that reflect the common use cases for the CLI.

It is my belief that there are broadly two sets of commands that one would issue through the CLI

  • OpenStack control plane management commands
  • OpenStack instance/cluster/database manipulation commands

The first is something we generally call the Management CLI today, the other is the 'trove' command.

I think the new openstack CLI should address both these use-cases.

Also, I believe that just as we have attempted to created a set of high level abstractions in Trove (instance, replica, cluster, ...) it would be good for the CLI to have a similar set of abstractions that are aligned NOT with the back-end abstractions but more with the use-cases for CLI.

I believe that the use-cases from the CLI include:

  1. Query Trove control plane configuration
  2. Update Trove control plane configuration
  3. Create Trove instance
  4. Create Trove cluster
  5. Create Trove replicated instance set
  6. Commands related to Trove replicated instances
  7. Commands related to Trove clusters
  8. Commands related to Trove instances
  9. Commands related to configuration parameters (addressing instances, replicated instances, and clusters alike)

For example, I anticipate that a user would like to do the following things:

  1. Create a single instance of MySQL
  2. Create a three member replicated set of MySQL instances with GTID based replication

While our current CLI allows us to do the first, the second is a multi-step process; create an instance and then create the two replicas.

That's just one example, but I want to summarize the biggest pain-point I see with the current Trove CLI as follows.

The Trove CLI today attempts to faithfully expose the Trove API rather than expose a set of operations that represent the kind(s) of thing(s) that a user would like to do with the CLI.

While I agree with the issue(s) raised above with respect to consistency, I think an independent and equally important issue is that we should attempt to make a CLI that is not just a think veneer around the API but rather reflective of the things one would like to do from the command line.

Furthermore, I believe that we should do this in a way that when we encounter a datastore in the future entirely unlike the ones we have today, the CLI is extensible and can accommodate that in a reasonable and intuitive way.

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