Difference between revisions of "UnifiedCLI"
(Redirected page to OpenStackClient) |
|||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | #REDIRECT [[OpenStackClient]] | |
| + | |||
= UnifiedCLI = | = UnifiedCLI = | ||
| − | Status: ''' | + | '''''Note: this page is being deprecated in favor of a new [[OpenStackClient|OpenStackClient]] page with the correct name.''''' |
| + | |||
| + | Status: '''In progress''' | ||
| + | |||
| + | The <code><nowiki>python-openstackclient</nowiki></code> project is underway and still alive but not completed. Progress for implementing the commands can be tracked in the [https://blueprints.launchpad.net/python-openstackclient blueprints], there is one for each corresponding [[OpenStack]] CLI binary. The short summary as of this writing is keystone and nova server commands are done. The [[/Mapping|command mapping]] shows the translation of the project cli commands to openstackclient. | ||
== Summary == | == Summary == | ||
| − | A unified [[OpenStack]] CLI will provide users with an improved experience in dealing with the variety of commands and arguments required to | + | A unified [[OpenStack]] CLI will provide users with an improved experience in dealing with the variety of commands and arguments required to interact with [[OpenStack]]. The unified CLI is intended to be a complete substitute for the bundled CLI binaries supplied with the [[OpenStack]] project clients. Where possible it will utilize the existing client modules to minimize duplication of effort. |
| − | == | + | === Supplemental Documents === |
| − | + | * [[/Mapping|Command Mapping]] | |
| + | * [[/HumanInterfaceGuidelines|Human Interface Guidelines]] | ||
| + | * [[/Authentication|Revised OSCLI Authentication]] | ||
== Rationale == | == Rationale == | ||
| − | The user experience with [[OpenStack]] CLI tools is a frustrating one right now due to a number of inconsistencies between the | + | The user experience with [[OpenStack]] CLI tools is a frustrating one right now due to a number of inconsistencies between the various tools, not to mention making a user know that <code><nowiki>keystone</nowiki></code> is the user/tenant tool and <code><nowiki>nova</nowiki></code> is the instance/flavor/image tools and <code><nowiki>glance</nowiki></code> is the image tool that replaces the image functions in <code><nowiki>nova</nowiki></code>. Those tools will remain as the reference implementation that comes bundled with the client libraries but a new unified (in spirit, if not in implementation) [[OpenStack]] CLI interface will provide a better user experience. |
| − | |||
| − | |||
| − | + | The existing binaries can be replaced with one (or more) binaries that have a uniform command structure and option usage. The intended model is similar to that used by <code><nowiki>git</nowiki></code> (multiple binaries front-ended by a single interface) or libvirt's <code><nowiki>virsh</nowiki></code> (a single monolithic binary that does everything) where they follow the form <code><nowiki>cli-tool command arguments</nowiki></code>. In addition, the virsh-like mode of an embedded command line can be supported that would be able to speed up operations by caching authentication and other data between commands. | |
== Goals == | == Goals == | ||
| − | |||
* use the [[OpenStack]] Python client API modules, extending them as required | * use the [[OpenStack]] Python client API modules, extending them as required | ||
| − | * use | + | * use consistent naming and structure for commands and arguments |
* consistent output formats with the option of reliably machine parsable formats | * consistent output formats with the option of reliably machine parsable formats | ||
| + | * use a single-binary approach that also contains an embedded command-line that can execute multiple commands on a single authentication (see libvirt's <code><nowiki>virsh</nowiki></code> for an example) | ||
* independence from the [[OpenStack]] project names | * independence from the [[OpenStack]] project names | ||
== Design == | == Design == | ||
| + | |||
| + | There is a [[/HumanInterfaceGuidelines|Human Interface Guidelines]] document being prepared that replaces this section. | ||
| + | |||
| + | The existing command sets for Keystone, Nova, Glance and Quantum have been mapped into the [[/Mapping|new command format]]. | ||
=== Command Structure === | === Command Structure === | ||
| − | + | The OpenStackClient has a consistent and predictable format for all of its commands. | |
| − | |||
| − | |||
| − | The | + | * The top level command name is <code>openstack</code> |
| + | * Sub-commands take the form: | ||
| + | <code>openstack [<global-options>] <object> <verb> [<second-object>] [<command-local-arguments>]</code> | ||
| + | '''''Note: The command format change was committed on 13May2013. This is the new format.''''' | ||
=== Command Arguments === | === Command Arguments === | ||
* All long options names shall use '-' as the interpolation character | * All long options names shall use '-' as the interpolation character | ||
| − | * [[/Authentication| | + | * Authentication options conform to [[/Authentication| a revised version of]] the original [[CLIAuth]] |
| − | + | * Global arguments generally have a corresponding environment variable that may also be used to set the value. If both are present, the command-line option takes priority. The environment variable names can be derived from the option by dropping the leading '--', converting all embedded dashes ('-') to underscores ('_'), and converting to upper case. | |
| − | + | * Positional arguments trail command options. Some commands require two objects be acted upon, both objects will appesr in the command subject and both positional arguments appear in the same order as in the command subject. | |
| − | |||
| − | |||
| − | * arguments that | ||
| − | |||
== Implementation == | == Implementation == | ||
| − | + | * Team: https://launchpad.net/python-openstackclient | |
| + | * Code: https://github.com/openstack/python-openstackclient | ||
| − | + | == Additional Information == | |
| − | == Other | + | === Other Resources === |
* Previous work in this vein is at [[UnifiedCommandLineClient]] | * Previous work in this vein is at [[UnifiedCommandLineClient]] | ||
* A Perl implementation is at https://metacpan.org/module/oscompute | * A Perl implementation is at https://metacpan.org/module/oscompute | ||
| − | |||
---- | ---- | ||
[[Category:Spec]] | [[Category:Spec]] | ||
Latest revision as of 02:11, 19 July 2013
Redirect to:
Contents
UnifiedCLI
Note: this page is being deprecated in favor of a new OpenStackClient page with the correct name.
Status: In progress
The python-openstackclient project is underway and still alive but not completed. Progress for implementing the commands can be tracked in the blueprints, there is one for each corresponding OpenStack CLI binary. The short summary as of this writing is keystone and nova server commands are done. The command mapping shows the translation of the project cli commands to openstackclient.
Summary
A unified OpenStack CLI will provide users with an improved experience in dealing with the variety of commands and arguments required to interact with OpenStack. The unified CLI is intended to be a complete substitute for the bundled CLI binaries supplied with the OpenStack project clients. Where possible it will utilize the existing client modules to minimize duplication of effort.
Supplemental Documents
Rationale
The user experience with OpenStack CLI tools is a frustrating one right now due to a number of inconsistencies between the various tools, not to mention making a user know that keystone is the user/tenant tool and nova is the instance/flavor/image tools and glance is the image tool that replaces the image functions in nova. Those tools will remain as the reference implementation that comes bundled with the client libraries but a new unified (in spirit, if not in implementation) OpenStack CLI interface will provide a better user experience.
The existing binaries can be replaced with one (or more) binaries that have a uniform command structure and option usage. The intended model is similar to that used by git (multiple binaries front-ended by a single interface) or libvirt's virsh (a single monolithic binary that does everything) where they follow the form cli-tool command arguments. In addition, the virsh-like mode of an embedded command line can be supported that would be able to speed up operations by caching authentication and other data between commands.
Goals
- use the OpenStack Python client API modules, extending them as required
- use consistent naming and structure for commands and arguments
- consistent output formats with the option of reliably machine parsable formats
- use a single-binary approach that also contains an embedded command-line that can execute multiple commands on a single authentication (see libvirt's
virshfor an example) - independence from the OpenStack project names
Design
There is a Human Interface Guidelines document being prepared that replaces this section.
The existing command sets for Keystone, Nova, Glance and Quantum have been mapped into the new command format.
Command Structure
The OpenStackClient has a consistent and predictable format for all of its commands.
- The top level command name is
openstack - Sub-commands take the form:
openstack [<global-options>] <object> <verb> [<second-object>] [<command-local-arguments>]
Note: The command format change was committed on 13May2013. This is the new format.
Command Arguments
- All long options names shall use '-' as the interpolation character
- Authentication options conform to a revised version of the original CLIAuth
- Global arguments generally have a corresponding environment variable that may also be used to set the value. If both are present, the command-line option takes priority. The environment variable names can be derived from the option by dropping the leading '--', converting all embedded dashes ('-') to underscores ('_'), and converting to upper case.
- Positional arguments trail command options. Some commands require two objects be acted upon, both objects will appesr in the command subject and both positional arguments appear in the same order as in the command subject.
Implementation
- Team: https://launchpad.net/python-openstackclient
- Code: https://github.com/openstack/python-openstackclient
Additional Information
Other Resources
- Previous work in this vein is at UnifiedCommandLineClient
- A Perl implementation is at https://metacpan.org/module/oscompute
