keystone-manage II
./bin/keystone-
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-
ERROR: invalid literal for int() with base 10: 'http://
Traceback (most recent call last):
File "./bin/
File "/Users/
raise exc
ValueError: invalid literal for int() with base 10: 'http://
If you'd like the complete headache, here's my full CLI session: http://
A (backwards-
- 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://
- 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:
- 2012.1
- Started by
- Ziad Sawalha
- Completed by
- Ziad Sawalha
Related branches
Related bugs
Sprints
Whiteboard
Example session:
$ ./manage create_user --name="john" --password=
1973bf70-
$ ./manage create_user --name="patrick" --password=
CREATED user id="2e46f230-
$ ./manage update_user --id="1973bf70-
$ ./manage list_users
[ pretty-printed table of users ]
$ ./manage list_users --csv
id,name
1973bf70-
2e46f230-
$ ./manage delete_user --id="1973bf70-
$ echo $?
0
$ ./manage delete_user --id="this-
FAILED to find user by id="this-
$ 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:/
Gerrit topic: https:/
Addressed by: https:/
Initial keystone-manage rewrite (bp keystone-manage2)
Addressed by: https:/
Implemented user & tenant CRUD (bp keystone-manage2)
Addressed by: https:/
Implemented bp keystone-manage2
Addressed by: https:/
Implemented subparsers (bp keystone-manage2)
Gerrit topic: https:/
Addressed by: https:/
Updated bp keystone-