keystone-manage II

Registered by Dolph Mathews on 2011-12-02

./bin/keystone-manage positional arguments are evil

The numerous positional arguments in the plethora of keystone-manage commands make it difficult to:

- Remember the syntax for a command
- Discover the syntax for a command
- Predict the outcome of a command
- Distinguish the meaning/context of an argument
- Change the CLI in the future
- Debug

Imagine the headache of trying to figure out what's wrong with the following management command:

    $ ./bin/keystone-manage endpointTemplates add 1 nova nova http://nova.openstack.org/ http://admin.nova.openstack.org/ http://192.168.1.50/ 1
    ERROR: invalid literal for int() with base 10: 'http://192.168.1.50/'
    Traceback (most recent call last):
      File "./bin/keystone-manage", line 16, in <module>
        keystone.manage.main()
      File "/Users/antiver/Dropbox/keystone/keystone/manage/__init__.py", line 293, in main
        raise exc
    ValueError: invalid literal for int() with base 10: 'http://192.168.1.50/'

If you'd like the complete headache, here's my full CLI session: http://paste.openstack.org/show/3614/ (which would be a *lot* longer if I cared about *what* was actually being created).

A (backwards-incompatible) revision should address:

- Not all commands should revolve around an "object type" (e.g. ./keystone-manage db_sync)
- I should not have to remember more than one positional argument
- Consideration should be made for managing remote keystone services in the future (e.g. --keystone="http://remote.keystone/"
- Everything should be interactively discoverable (intuitive feedback on errors, comprehensive help text)
- It should be *very* easy to implement a new command, or find/review/revise an existing one

Blueprint information

Status:
Complete
Approver:
Ziad Sawalha
Priority:
Medium
Drafter:
Dolph Mathews
Direction:
Approved
Assignee:
Dolph Mathews
Definition:
Discussion
Series goal:
Accepted for essex
Implementation:
Implemented
Milestone target:
milestone icon 2012.1
Started by
Ziad Sawalha on 2011-12-21
Completed by
Ziad Sawalha on 2012-01-20

Related branches

Sprints

Whiteboard

Example session:

$ ./manage create_user --name="john" --password="secrete"
1973bf70-1d2f-11e1-8bc2-0800200c9a66
$ ./manage create_user --name="patrick" --password="moresecrete" --verbose
CREATED user id="2e46f230-1d31-11e1-8bc2-0800200c9a66"
$ ./manage update_user --id="1973bf70-1d2f-11e1-8bc2-0800200c9a66" --name="john"
$ ./manage list_users
[ pretty-printed table of users ]
$ ./manage list_users --csv
id,name
1973bf70-1d2f-11e1-8bc2-0800200c9a66,john
2e46f230-1d31-11e1-8bc2-0800200c9a66,patrick
$ ./manage delete_user --id="1973bf70-1d2f-11e1-8bc2-0800200c9a66"
$ echo $?
0
$ ./manage delete_user --id="this-does-not-exist"
FAILED to find user by id="this-does-not-exist"
$ echo $?
1

Additional considerations:
- Default output should be limited on successful cases
- Output should be parseable (or available as parseable)
- Success/failure should always be indicated by the status code returned

Bug list for keystone-manage: https://bugs.launchpad.net/keystone/+bugs?field.tag=keystone-manage

Gerrit topic: https://review.openstack.org/#q,topic:bp/keystone-manage2,n,z

Addressed by: https://review.openstack.org/2511
    Initial keystone-manage rewrite (bp keystone-manage2)

Addressed by: https://review.openstack.org/2887
    Implemented user & tenant CRUD (bp keystone-manage2)

Addressed by: https://review.openstack.org/3123
    Implemented bp keystone-manage2

Addressed by: https://review.openstack.org/3224
    Implemented subparsers (bp keystone-manage2)

Gerrit topic: https://review.openstack.org/#q,topic:bp/keystone-configuration,n,z

Addressed by: https://review.openstack.org/3383
    Updated bp keystone-configuration for bp keystone-manage2

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.